











REPORT NO. 4: MANAGEMENT APPROACH 
RECOMMENDATIONS 


Prepared For 

NATIONAL AERONAUTICS AND SPACE ADMINISTRATION 
GODDARD SPACE FLIGHT CENTER 
GREENBELT, MARYLAND 20771 


Prepared By 

GRUMMAN AEROSPACE CORPORATION 
BETHPAGE, NEW YORK 11714 


September 1974 



CONTENTS 


Section Page 

1 INTRODUCTION 1-1 

2 MANAGEMENT APPROACH RECOMMENDATION 

SUMMARY. 2-1 

2.1 Program Approach 2-1 

2.2 Program Management 2-2 

2.3 Employment of a Flexible System Integration 

Team Concept 2-2 

2.4 Direct Use of NASA Personnel in System Integration 

Functions . 2-3 

2.5 Contracting Techniques Between the Government and 

the Prime Contractor ; 2-3 

2.6 Contracting Techniques Between the Prime Contractor 

and Subcontractors 2-4 

2.7 Subcontracting Techniques for the Modules ....... 2-5 

2 . 8 Manufacturing 2-5 

2.9 Test Philosophy * . . 2-6 

2.10 Documentation and Controls 2-6 

2.11 Baselines and Configuration Control 2-6 

2.12 Maintenance of Commonality 2-7 

2.13 Summary of Cost Savings 2-7 

3 MANAGEMENT APPROACH RECOMMENDATIONS. ... 3-1 

3.1 Program Approach 3-1 

3.2 Program Management 3-2 

3. 3 = Contracting Techniques Between the Government and the 

Prime Contractor 3-11 

3.4 Contracting Techniques Between the Prime Contractors 

and Subcontractors 3-15 

3.5 Manufacturing * 3-19 


iii 



CONTENTS (Cont) 

CONTENTS 

Section 

3.6 ' Test Philosophy 3-21 

3.7 Reliability and Quality Assurance 3-27 

3.8 Documentation and Controls 3-28 

3.9 Requirements Specification 3-31 

3.10 Customer Approval Levels . . ♦ 3-35 

3.11 Baselines and Configuration Control 3-35 

3.12 Maintenance of Commonality 3-36 

4 MANAGEMENT APPROACH ALTERNATIVES 4-1 

4.1 Contracting Techniques Between the Government and 

the Prime Contractor 4-1 

4.2 Contract Types . . . . ,4-4 

4.3 Subcontract Management Techniques 4-5 

4.4 Reliability and Quality As surance 4-7 

4.5 Testing Philosophy 4-11 

4.6 Documentation and Controls 4-11 

4.7 Baselines and Configuration Control 4-28 


iv 



ILLUSTRATIONS 


Figure 

3-1 

3-2 

3-3 

3-4 

3-5 

3-6 

3-7 

3-8 

3 - 9 

4 - 1 
4-2 
4-3 
4-4 


Design-to-Cost Activity Flow 

System Integration Team 

Management System Operation 

EOS Phase C/D Work Breakdown Structure 

Program Master Schedule , . . 

EOS Program Development 

EOS Flight Hardware Test Program and Flow 

Flight Hardware Development and Qualification Test Summary . 

EOS Flight and Ground Software and Ground System 
Integration and Test 

CM Documentation Tree 

Costs of a Product Related to Specification Requirements .... 
Document Control Levels . . , . . . , 

Optimum Baseline 


Page 

3-5 

3-6 

3-8 

3-9 

3-13 

3-17 

3-23 

3-24 

3 - 26 

4 - 17 
4-18 
4-29 
4-31 


Table 

2-1 

3 - 1 

4 - 1 
4-2 
4-3 
4-4 


TABLES 


Summary of Cost Savings 

EOS System Integrator Team Members, a Typical 
Distribution 

Contract Types 

EOS Subcontract Management Techniques .... 

Reliability Issue 

Quality Assurance Issues 


Page 


2-7 


3-7 


4-4 

4-6 

4-8 

4-11 


v 



INTRODUCTION 



4 


' 1-INTRODUCTION 

This Management approach for EOS has been developed at the point where the United 
States has completed 17 years of Space Technology experience. This period has been 
characterized by tremendous space advancements, the most notable of which was the land- 
ing of man on the moon. But equally or more complex and demanding in both the technical 
and management areas have been the wide range of observatory, scientific and communica- 
tion satellites that have been developed and launched. More than 700 Space launches were ' 
made during this 17 -year period. In short, the United States has met the challenges of 
space and overcome many of its obstacles. 

Included among the technical accomplishments during this period is the development 
of Systems Engineering and System Management techniques, new standards in reliability 
and quality control and further perfection of fabrication, integration, and testing techniques. 
All of these elements have contributed to produce a wide range of hardware which is 
qualified, tested, and proven for use in the space environment. During this time, hundreds 
of thousands of people were trained to work in the demanding and complex space environ- 
ment, and they have demonstrated their capability with a near -flawless record of space 
flights. 

We are now faced with new challenges to continue to advance technology and improve 
management techniques in a new environment: that of constrained cost. The application 
of the lessons learned during the early years of space are now being directed to this new 
challenge. 

This report recommends a management approach which will meet the challenge of a 
constrained cost environment. The requirement of this study has been to explore manage- 
ment approaches to achieve a low cost program. Suggested areas for study include con- 
tracting techniques, test philosophy, reliability and quality assurance requirements, com- 
monality options, and documentation and control requirements. 

To prepare a data bank for management approaches, interviews were held with 
personnel experienced in the management of programs covering a wide range of require- 
ments and products. NASA, DOD, DOT and commercial programs were reviewed for 
alternate management approaches. 
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Functional areas such as manufacturing, program planning and control, reliability, 
quality assurance, test, contracting, subcontracting and configuration/data management 
have been examined for alternate methods of doing business in a way that would result in a 
lower cost or a more efficient program with emphasis on the requirements of a program 
such as the EOS. A publication search has been conducted to determine what experiences 
and recommendations would contribute to this study. 

With this ’databank* in hand, we have looked at the EOS program to determine which 
areas may be most suitable for the application of alternate approaches, and what manage- 
ment techniques could be applied to most effectively manage the program. 

This report describes our recommended management approach, and is presented in 
the following order: 

• Section 2, Management Approach Recommendation Summary 

• Section 3, Management Approach Recommendations 

• Section 4, Management Approach Alternatives. 
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2-MANAGEMENT APPROACH RECOMMENDATIONS SUMMARY 
2. 1 PROGRAM APPROACH 

We recommend that the Earth Observatory Satellite (EOS) Program and the follow-on 
earth observation mission programs be conducted in a controlled target cost environment. 

In this environment, the program approach must ensure program requirements are met 
within allocated budgets. 

Since the EOS program has relatively low production volume, and development cost 
is a major fraction of total program cost, the recommended program approach is Design- 
to-Cost (DTC) on a total Program Acquisition Cost basis. 

The DTC program acquisition approach offers specific advantages in assuring that 
essential program requirements are controlled within allocated budgets. This approach 
requires innovative designs and functional concepts. It establishes the mechanism by which 
cost visibility is provided both to designer and. management and requirements/cost incom- 
patitibilies can be directed for higher level resolution. Cost/schedule/performance 
tradeoffs are conducted above minimum essential performance requirements. The net 
result is a lower risk program, and will maintain a total program cost within prescribed 
limits by designing to established cost goals and trading performance against cost for 
selected program requirements. This approach will reduce the cost of the EOS-A and -A’ 
development by approximately $11 million. 

In the DTC approach, system definition studies will have established program require- 
ments and DTC goals. Program requirements will be categorized as mandatory or desir- 
able. The DTC goals will be target budgets for major program WBS elements, such as 
Spacecraft, Instruments, Ground Station, Data Processing, etc. Where the program 
implementation produces an out-of-tolerance condition, the problem will be resolved by 
re-allocation between WBS elements and/or modification of desirable requirements. The 
net effect will be to maintain a total program cost within prescribed limits by designing to 
established cost goals, and trading performance against cost for selected program 
requirements. 
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2.2 PROGRAM MANAGEMENT 

To manage the program implemented in accordance with the DTC approach, we 
recommend a System Integration team headed by a centralized program manager which 
we have designated as the System Integrator. This program manager, responsible to 
the NASA/Goddard EOS Project Manager, is the system contractor for the Basic Space- 
craft, Control Center and Mission Controls, Mission Peculiar Spacecraft, Central Data 
Processing Facility and Low Cost Ground Station. In addition to the above responsibilities, 
the System Integrator is responsible for assessing the performance of the Instrument and 
System GFE contractors. The scope of this assessment includes cost, schedule, and 
technical performance. Where cost, schedule, or technical problems develop that cannot 
be handled within the latitude of the specific contract, the System Integrator will perform 
an in-depth analysis of the problem, conducting cost/performance/requirements trades as 
necessary. Resultant recommended program modifications to maintain total program costs 
within established goals are forwarded by the System Integrator to the NASA EOS Program 
Manager for review, approval and implementation. 

2.3 EMPLOYMENT OF A FLEXIBLE SYSTEM INTEGRATION TEAM CONCEPT 

We envision the System Integrator in his total program role functioning with a 
working team. This working team, under System Integrator leadership, will include 
personnel from NASA/Goddard, user groups, GFE contractors, and the instrument 
contractors. 

This team concept differs from normal management approaches in that it establishes 
a working group with the most knowledgeable personnel from each of the participants in 
the EOS program. Each member of the team will have his responsibilities defined, and 
each will contribute to the program without duplication of effort. 

Use of this working team will reduce documentation requirements because the 
various program groups will be intimately involved in program assessment and modifica- 
tion as active team members. Other advantages of this concept are shortened response 
times, and ability to vary team mix as program focus varies through the program 
phases. As a matter of fact, the System Integrator responsibility may very well be 
assigned to other contractors for follow-on earth observation missions. NASA/Goddard, 
System Integrator, and team member responsibilities will be detailed through contractual 
interface documents and memorandum of agreement. 
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Management of a DTC/Program Acquisition Cost program requires a total manage- 
ment system for effective implementation. The management system must include a DTC 
system whereby major WBS cost budgets are sub-divided down to the lowest level where 
work is performed, namely: the Work Package Level. 

The management system, in addition to the DTC system, must include a cost/ 
schedule control system and a technical performance measurement system. The 
cost/schedule control system monitors, on a monthly basis, cost and schedule performance 
at various WBS levels against established targets. Technical performance management 
functions in the same manner, using technical parameters as target. 

2.4 DIRECT USE OF NASA PERSONNEL IN SYSTEM INTEGRATION FUNCTIONS 

We suggest that the System Integration team for EOS-A and -A 1 consist of approx- 
mately 10 GSFC/NASA personnel who will contribute directly to the EOS system develop- 
ment by performing portions of the system design and system requirements. This approach 
will reduce the contractor efforts by approximately $1 million. 

MODERATE SIMPLIFICATION OF CONTROLS, DOCUMENTATION AND TEST - The Sys- 
tem Integration team will reduce the documentation necessary for visibility and control of 
the EOS program by the Government. Documentation should be minimal and in accordance 
with contractor formats for drawings, financial reports and failure analysis - to name a few 
examples. The approximate savings for this approach is $1. 25 million. 

LOW-COST MINIMUM RISK TEST PROGRAM - A low-cost test program, without high risk, 
includes system and component environmental acceptance testing at the module level; the 
basic spacecraft structure and modules are qualified for follow-on, as well as the basic 
mission; and separate component and module qualification testing. This approach will save 
$1.8 million. 

2.5 CONTRACTING TECHNIQUES BETWEEN THE GOVERNMENT AND THE PRIME 
CONTRACTOR 

The contractual techniques recommended for the DTC EOS-A and -A 1 phase of the pro- 
gram considers the cost risk of the major elements of the EOS program and shares this 
cost risk between the Government and the contractor to reduce the program cost to the low- 
est level. The EOS-A and -A 1 phase is also planned to permit the introduction of production 
procurements of the Basic Spacecraft and the Low Cost Ground Station and provides alternate 
methods of future procurement. 
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The Instruments and the DMS operations for the initial flights are procured by the 
Government and provided to the System Integrator as GFE. The System Integrator will 
manage the Instrument contractors through the System Integrator team, and will resolve 
interfaces within the team or by an Interface Board, For any problems requiring NASA/ 
Goddard Project Management approvals, recommendations will be provided by the System 
Integrator and the Instrument contractor. The System Integrator will supply the necessary 
assistance to the NASA/Goddard Project Manager for the procurement and interface to fully 
integrate the Instruments into the DTC goals. This approach will reduce the program cost 
for EOS-A and -A T by approximately $15.6 mil lion. 

The System Integrator is the prime contractor for the EOS-A and -A ' mission, includ- 
ing the Basic Spacecraft, Control Center and Mission Control, Mission Peculiar Spacecraft, 
Central Data Processing Facility and Low Cost Ground Station. 

We recommend that this selection be made at the earliest time to begin the develop- 
ment of the Basic Spacecraft and to establish the System Integration of the Instruments. 

To expedite this selection, we recommend that a preliminary RFP be issued to the con- 
tractors for comments. This review will provide a better understanding by Goddard and 
the contractor when the official RFP is issued. 

The competition for the EOS-A and -A 1 execution phase will be a management and 
technical competition with the DTC goals fixed from information NASA has received from 
the System Definition Study and the funds allotted for the program. Costs will be allocated 
in this proposal to assist in understanding of the management approach. Total funding and 
fiscal funding requirements may be established. 

This contractual plan makes full use of a DTC philosophy and presents a low-cost 
approach to the EOS-A and -A ' execution phase. It provides the structure to manage within 
the program funding, and the flexibility to control within fiscal year funding. An early 
selection of the System Integrator will assist in the Instrument procurement and assist in 
optimum planning for the Basic Spacecraft. The development of a Basic Spacecraft will 
also enhance future space programs by providing standard spacecraft hardware for low- 
cost space programs. 

2. 6 CONTRACTING TECHNIQUES BETWEEN THE PRIME CONTRACTOR AND 
SUBCONTRACTORS 

Subcontracting will be conducted within DTC goals and desirable requirements will be 
identified. 
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Because the seller assumes the highest degree of risk under fixed price contracting, 
flexible type contracting should be minimized. Maximum use of "off the shelf” components 
would appear to complement the use of fixed price contracting. Flexible -type contracting 
would be used on a selective basis. Where practical, individual subcontracts would be 
segmented to isolate the areas of uncertainty that lend themselves to flexible pricing; if 
necessary, a delay in contracting of later phases until definition is sufficiently clear to per- 
mit firm pricing is thus possible. 

Pooling procurement of critical components common to several subcontractor's 
equipment has been found beneficial from a cost, schedule, and quality viewpoint. In these 
instances, Grumman and the Government can benefit from the lower cost resulting from 
larger volume procurement, as well as maintain greater control over uniform quality of the 
parts. 

As part of the evaluation process of all seller proposals, a risk analysis will be pre- 
pared. This analysis will identify specific areas of risk in schedule, cost, and technical 
performance. In instances where competitive procurement is indicated, tills analysis will 
become part of the selection criteria. In addition, the analysis will provide the basis for 
planning the procurements in a way that minimizes program impact. 

To minimize total program cost by maximum use of available Government supplies 
and services, the Government will be considered a potential supplier in areas such as 
special test equipment, residual flight hardware, engineering services, and test facilities. 
Program requirements in these areas will be by the System Integrator team to ensure taking 
advantage of opportunities that may. exist. It is estimated that 10% of the procurement cost 
may be saved by this approach. - 

2.7 SUBCONTRACTING TECHNIQUES FOR THE MODULES 

For the design and development of the modules, a comparison between development 
by the prime contractor or by the prominent supplier of the module components indicates a 
15% savings if the module is developed by the prime contractor. This is based upon data on 
the EOS Attitude Control System Module. An additional 15% may be saved by substituting 
components from a wide variety of suppliers. In the production phase of the modules, no 
significant difference in cost is indicated. 

2.8 MANUFACTURING 

Manufacturing techniques and procedures recommended for the DTC EOS Program to 
reduce the manufacturing segment of the overall program costs include support of Design- 
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to-Cost activities, maximum build for standard parts, use of a "limited production" manu- 
facturing approach for small quantity parts, and a manufacturing Verification System to 
increase personnel motivation to "do it right the first time. " 

2„ 9 TEST PHILOSOPHY 


The test trade studies define and evaluate the influences of the EOS design and system 
development approaches on the cost of Development, Qualification, Integration and Accep- 
tance testing for the Spacecraft for the EOS Land Resources Mission and follow-on missions. 

The significant areas of cost savings /impact identified by the test trade studies are: 

• Savings of $500 dollars which represent 50% of the Environmental Acceptance 
Test Costs at virtually no increase in risk, by combining all System and Com- 
ponent environemntal acceptance tests at the module level 


a Modularity and follow-on mission qualification requirements add $125 thousand to 
the qualification test cost; however, the flexibility and savings in total test costs 
provided by the modular common spacecraft, over integrated dedicated space- 
crafts for each mission, more than offsets the added $125 thousand in qualification 
test costs imposed on the basis EOS program. 

2. 10 DOCUMENTATION AND CONTROLS 


The low-cost management techniques for documentation and controls will provide 
NASA with visibility of EOS progress, and enchance mutual confidence without excessive 
documentation and control. The recommendations will provide NASA with all of the basic 
information it needs to measure and guide program performance, while simplifying and re 
ducing the correlary cost of documentation review, ordering, delivery, storage and re- 
trieval, specification requirements, configuration baselining, and change control. Our 
recommended use of the System Integrator team will reduce formal documentation to a 
minimum and increase visibility to a maximum. Cost savings are approximately $1.25 
million. 


2.11 BASELINES AND CONFIGURATION CONTROL 

For optimum baseline, the recommendations for the establishment of the product 
baseline are: Select the point in the program for establishment of the product baseline at 
or near the point of design stabilization to avoid an unnecessary and burdensome change 
mill. Dependent upon overall program schedule, portions of the system should be baselined 
independently at an optimum point for that segment. 
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2. 12 MAINTENANCE OF COMMONALITY 

One of the objectives of our study has been to provide a Basic Spacecraft which can 
accommodate a variety of follow-on missions. This philosophy is carried through to all 
aspects of the recommended hardware design, management approach, procurement plan, 
and test philosophy. 

The basic spacecraft design is flexible enough to support the LRM, Marine Resources, 
Ocean Dynamics, Weather Observation and Transient Environmental phenomena. The rec- 
ommended management approach provides a concept of a System Integrator which maintains 
a nucleus of people supple mented by the various team elements dependent on the emphasis 
of integration difficulty. The Basic Spacecraft contractor participation in the System In- 
tegration Team assures the continuity of experience, test and checkout procedures and 
techniques, and GSE from mission to mission, 

2.13 SUMMARY OF COST SAVINGS 

Table 2-1 summarizes the cost savings that will be attained in the categories de- 
scribed in the foregoing subsections. 


Table 2-1 Summary of Cost Savings 


1 

CATEGORY 

SAVINGS, $, MILLIONS 

• DESIGN-TO-COST 

$ 11.0 

• SYSTEM INTEGRATOR TEAM 

1 

- NASA PERSONNEL PARTICIPATION 

1.0 

- DOCUMENTATION AND CONTROLS 

1.25 

• TESTING 

1.30 

• GRE INSTRUMENTS & DMS OPERATIONS 

15.60 

TOTAL 

$30.65 MILLION 
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3 - MANAGEMENT APPROACH RECOMMENDATIONS 
3.1 PROGRAM APPROACH 

It is recommended that EOS program and the follow-on earth observation mission 
programs will be conducted in a controlled- target cost environment. In this environment 
the program approach must ensure that program requirements are met within allocated 
budget. 

Experience has shown that program requirements within specified ranges can be 
obtained within specific budget costs. Although programs have achieved these results most 
commonly through a Design-to-Cost (DTC) approach to unit production costs, they have 
achieved similar results through a DTC approach for the total program. Since the EOS 
program has relatively low production volume and development cost is a major fraction 
of total program cost, the recommended program approach is Design-to-Cost on a total 
Program Acquisition Cost basis. Program acquisition offers specific advantages to 
insuring that essential program requirements are controlled within allocated budgets. 

This approach requires innovative designs and functional concepts. It establishes the 
mechanism by which cost visibility is provided both to designer and management, and re- 
quirements/ cost incompatibilities can be directed for higher level resolution. Cost/ 
schedule/performance tradeoffs are conducted above minimum essential performance re- 
quirements. The net result is a lower risk program because of the 

• Tendency to utilize proven hardware of known cost 

• Flexibility to modify requirements and trade performance versus cost 

• Synergistic effect of the two foregoing elements 

• Active participation of customer personnel in performance/cost trades to assure 
that maximum cost obligations are not exceeded. 

The DTC/Program Acquisition Cost approach may seem to have the disadvantage 
of discouraging incorporation of new technology into spacecraft applications. Obviously, 
it requires frequent meetings and communication between customer and contractor, 
contractor and his subcontractors, and contractor and associate contractors. Furthermore, 
program requirements must be categorized as mandatory or desirable. Lastly, the DTC 
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approach requires the availability and utilization of a management system to provide the 
cost motivation and program status key. 

Although on the surface a management system which requires relatively more disci- 
pline and formality may seem costly, inhibit flexibility, and therefore be a disadvantage, 
our recent experience with similar systems indicates the reverse is true. Our experience, 
giving full consideration to the advantages and disadvantages of the DTC /Program Acqui- 
sition Cost approach and the requirements of the EOS program/system, makes us recom- 
mend the application of this approach based on its ability to best satisfy the particular 
characteristics of the EOS program. 

In our approach, system definition studies will have established program require- 
ments and design-to-cost goals. The program requirements will be categorized as 
mandatory or desirable. The DTC goals will be target budgets for major program WBS 
elements such as Spacecraft, Instruments, Ground Station, Data Processing, etc. Where 
the program implementation produces an out-of-tolerance condition, the problem will be 
resolved by re- allocation between WBS elements and/or modification of desirable require- 
ments. The net effect, then, will be to maintain a total program cost within prescribed 
limits by designing to established cost goals and trading performance against cost for 
selected program requirements. This approach will reduce the cost of the EOS-A and 
-A 1 development by approximately $11 million. 

3.2 PROGRAM MANAGEMENT 

The program, implemented in accordance with the approach described above, would 
be managed by a centralized program manager whom we have designated as the System. 
Integrator. This program manager, responsible to the NASA/Goddard EOS project 
manager, is the basic system contractor program manager. He will have overall respon- 
sibility for the basic system, including the Basic Spacecraft, Control Center and Mission 
Controls, Mission Peculiar Spacecraft, Central Data Processing Facility and Low Cost 
Ground Station. In addition to the foregoing responsibility, the System Integrator is also 
responsible for assessing the performance of the Instrument and System GFE contractors. 
The scope of this assessment includes cost, schedule, and technical performance. Where 
cost/schedule or technical problems develop that cannot be handled within the latitude of 
the specific contract, the System Integrator will perform an in-depth analysis of each 
problem, conducting cost/performance and requirements trades as required. He will 
then recommend program modifications to maintain total program costs within established 
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goals to the NASA EOS Program Manager for review and approval, whereupon he will 
implement them. The System Integrator concept will also be effective if any program 
requirement or projected cost reaches an incompatible impasse. In this instance, the 
System Integrator would flag the problem, identifying potential alternate solutions for 
early corrective action by the NASA EOS Project Manager. This concept of program 
management is shown in Fig. 3-1. 

We envision the System Integrator in his total program role functioning through a 
working team concept. Under the System Integrator leadership, this team will include 
personnel from NASA/Goddard, user groups, GFE contractors, and the Instrument con- 
tractor. This team concept differs from normal management "team approach" in that it 
establishes a working group with the most knowledgeable personnel from each of the par- 
ticipants in the EOS program. Each member of the team will have his responsibilities 
defined; each will contribute to the program without duplication of effort. The team makes 
it possible to address all functions of the EOS program, and either resolve program prob- 
lems or conduct the in-depth analysis/trades necessary to formulate problem-solving 
recommendations for the NASA/Goddard project manager. The team for EOS-A and -A' 
is shown on Fig. 3-2. 

The working team concept will reduce documentation requirements because the 
various program groups will be intimately involved in program assessment and modification 
as active team members. Other advantages of this concept are shortened response times 
and ability to vary team mix as program focus varies through the program phases. As 
a matter of fact, the System Integrator responsibility may very well be assigned to other 
contractors for follow-on earth observation missions. NASA/Goddard, System Integrator, 
and team member responsibilities will be detailed through contractual interface documents 
and a memorandum of agreement. A typical distribution for several different missions 
is shown on Table 3-1. 

In addition to the normal expertise contributed by Government personnel, other 
tasks directly applicable to the EOS program will be performed by Government team 
members. Verification requirements definition/planning review, residual flight and 
ground support equipment survey for EOS use, and cost effective utilization of Government 
facilities are examples of the tasks which could be performed. This direct use of NASA 
personnel will reduce contractor cost by about $1 million. 

Proposed utilization of Government facilities is the type of recommendation that 
would be made to the NASA/Goddard project manager. The System Integrator and his 
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team would also provide a central source of current program information to assist in 
future mission planning by the NASA/Goddard project manager and other Governmental 
agencies. 

Management of a DTC/Program Acquisition Cost program requires a total manage- 
ment system for effective implementation. The management system must include a DTC 
system wherein major WBS cost budgets are subdivided down to the lowest level where 
work is performed: the Work Package Level. The DTC system must provide budget 
visibility for design, manufacturing, test and procurement personnel as well as program 
management personnel. It must provide the cost visibility necessary for design iterations 
and innovative trade studies to be performed to establish configuration and detail designs 
that are consistent with allocated budgets. Designers must have total responsibility for 
both cost and performance of their work packages. To efficiently carry out these respon- 
sibilities, they are armed with tools such as Designer’s Cost Manuals, Equipment Data 
Bank, etc. These tools provide the designer with the capability to estimate the cost of 
a particular design prior to release of a design for manufacturing, procurement, and 
test activities. This system also provides the capability of flagging for higher level 
action those areas where budgets/requirements are incompatible. 

The management system, in addition to the DTC system, must include a cost/sched- 
ule control system and a technical performance measurement system. The cost/schedule 
control system monitors, on a monthly basis, cost and schedule performance at various 
WBS levels against established targets. Allowable tolerances are established for each 
target and related to the current, cumulative-to-date, and at-completion time periods. 

If cost and/or schedule performance go out of the established tolerance, program manage- 
ment must document the condition and successfully close it via a variance analysis report. 

The technical performance measurement system is comparable to the cost/schedule 
control system. Technical performance measurement parameters are established with 
expected results and allowable tolerances. The particular parameters selected for 
performance measurement include key parameters for items such as system performance 
assessment, customer’s performance priorities , mission success criticality, and con- 
tract demonstration incentives. These items are tracked monthly; the specific parameters 
(for example, spacecraft weight, mean mission duration, power amplifier, power output, 
etc) are measured against allowable thresholds. Out-of-tolerance conditions require 

documentation and corrective action comparable to that of the cost/schedule control 
system. 
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Fig. 3-1 Design-to-Cost Activity Flow 











* BASIC SYSTEM CONTRACTOR FOR EOS A A'. 
FOR FOLLOW-ON MISSIONS MAY BE OTHER 
CONTRACTOR OR AGENCY. 
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Fig. 3-2 System Integration Team 
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Table 3-1 EOS System Integrator Team Members, A Typical Distribution 



EOS 

OPERATIONAL 

MARINE 

WEATHER 

— 

A AND A' LRM 

LRM 

RESOURCES 

OBSERVATION 

SVS. INTEG-CONTR (2) 

20 

20 

30 

30 

GOVERNMENT 


' 



NASA/GSFC 





LOW COST SYS (1) 



2 

10 

JPL 



1 

1 

DEPT INTERIOR ■ 

2 



— 

D. AGRICULTURE 



2 

- 

NOAA, D. COMM 




— 

NASA/ULO (1) 

1 


5 

4 

SCIENCE CONSULTANTS (21 

2 

2 

1 

1 

INSTR. CONTR. 

4 

5 

4 

4 

BASIC SPACECRAFT 

INCLUDED IN 

2 

2 



SYSTEM INTEGRATION 




LAUNCH VEHICLE (1) 

1 

1 

1 

i 


(1) PART TIME 

<2) EQUIV. MEN MIX CHANGES BASED ON MISSION 
3-199 
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The management system operation for this approach, integrating the DTC, Cost/ 
Schedule control, technical performance measurement systems, is shown in Fig. 3-3. 

While this program approach and management system should be applied to the total program 
and to the major WBS elements, certain major WBS elements (such as the launch vehicle) 
do not lend themselves to a DTC approach for program acquisition cost. Nevertheless, 
this does not preclude handling the total program on the recommended approach, nor 
does it exclude the application of this technique to those major WBS elements that do 
require significant design and development. 

We recommend that the existing format of the contractor's performance system 
be utilized to provide the inputs required for the System Integrator program management. 

Key elements in our program management are the Work Breakdown Structure (WBS), 
the Program Schedule, and the Action Center. The WBS provides the basic task structure 
to identify and define all program tasks and to establish summary levels for financial, 
manpower, and procurement planning. Reports to NASA/Goddard for cost and schedule 
performance, at one level below the Goddard project report to Goddard management, and 

will be in accordance with the WBS. The WBS planned for the EOS program is detailed 
in Fig. 3-4. 

Relative to schedule, the EOS program has numerous interface functions that must 
be defined to assure successful accomplishment. The System Integrator must be given 
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the time to initially schedule the various activities so that an optimum schedule can be 
established for each element of the EOS program. Planning must be based on realistic 
schedules for the events and within the DTC funding goals. The System Integrator and 
team members reschedule events, subject to NASA/Goddard project manager approval, 
to perform within DTC goals and to adjust to program problems, funding constraints, 
and user requirements. The recommended EOS schedule based on current program 
assessment is shown in Fig, 3-5. 

The Action Center is recommended as the most cost effective way to display EOS 
program plans, status, and trends. This is a working session area displaying cost, 
schedule, and technical performance data for the total EOS program. Here, lower level 
WBS data is available to Goddard in support of the top level report. 

3. 3 CONTRACTING TECHNIQUES BETWEEN THE GOVERNMENT AND THE 
PRIME CONTRACTOR 

The contractual techniques recommended for the Design-to-Cost EOS- A and A T phase 
of the program and shares this cost risk of the major elements of the EOS program and 
shares this cost risk between the Government and the contractor to reduce the program cost 
to the lowest level. The EOS- A and A f phase is also planned to permit the introduction of 
multiple procurements of the Basic Spacecraft and the Low Cost Ground Station, and provides 
alternate methods for future procurement. 

The Instruments and DMS operations for the initial flights are procured by the 
Government and provided to the System Integrator as GFE. The System Integrator will 

manage the Instrument contractors through the System Integrator team and will resolve 
interfaces within the team or by an Interface Board. For any problems requiring NASA/ 
Goddard project management approvals, recommendations will be provided by the System 
Integrator and the Instrument contractor. The System Integrator will supply the nec- 
essary assistance to the NASA /Goddard Project Manager for the procurement and inter- 
face to fully integrate the Instruments into DTC goals. This arrangement will reduce 
EOS program cost by approximately $15.6 million. 

The candidate Instruments for the EOS program are in high risk and low risk 
categories. The Thematic Mapper, HR PI, PMMR, SAR, SE OS and Solar Maximum 
have a higher development risks it is recommended that cost type contracting is appro- 
priate; Instruments (such as the Data Collection System (DCS) and certain SEASAT 
instruments) are of sufficiently low risk to procure by either a firm fixed price contract 
or a fixed price incentive contract. 
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The Launch Vehicle, Shroud, FSS, MEMS and modifications to the Data Acquisition 
Station are to be procured under the normal Government procurement practices. As 
members of the System Integrator team, representatives of these procurements will 
participate in the EOS program at the associate contractor level; the funding for these 
efforts will be part of the System Integrator DTC goals. 

The System Integrator is the prime contractor for the EOS-A and -A’ mission, 
including the Basic Spacecraft, Control Center and Mission Control, Mission Peculiar 
Spacecraft, Central Data Processing Facility and Low Cost Ground Station. 

We recommend that this selection be made at the earliest time to begin the develop- 
ment of the Basic Spacecraft and to establish the System Integration of the Instruments. 

To expedite this selection, we recommend that a preliminary RFP be issued to the 
contractors for comments. This review will provide a better understanding by Goddard 
and the contractor when the official RFP is issued. 

The competition for the EOS-A and -A' execution phase will be a management and 
technical competition. The Design-to-Cost goals will be fixed from information NASA 
has received from the System Definition Study, and from the funds allotted for the pro- 
gram. Costs will be allocated in this proposal to assist in the understanding of the 
management approach. Total funding and fiscal funding requirements may be established. 

, A cost -type contract should be used for this procurement. In accordance with the 
objectives of a DTC program, and as required by the System Integrator responsibility to 
manage within the DTC goals, cost tradeoffs will be a continuous requirement. A specific 
incentive goal could be provided for this management effort if it can be clearly defined 
and measured, and will not hamper the trades which might be required during the program. 

Several candidates for fixed price contracting are identified with alternate procure- 
ment techniques. The Basic Spacecraft, Modules and the Low Cost Ground Station may be 
procured by fixed price contracts following their development. For follow-on missions, 
the Basic Spacecraft or selected Modules can be procured by the Government and supplied 
to a System Integrator GFE (Option A), or a procurement package including drawings and 
specifications which can be supplied for use by the System Integrator (Option B). The Low 
Cost Ground Station can be procured similarly. The Low Cost Ground Station can be 
procured by the Government for use by the users (Option A), or the procurement package 
could be provided for the use of the user (Option B). 
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The DMS operations (including the Mission Control, Data Processing operations 
and support) should be contracted by a time-and-material or labor-type basis. Each 
contract should be by individual contracts, rather than by the System Integrator for 

maximum direct procurement - a DTC approach is not of significant value during this 
phase of the contract. 

The overall contractual plan makes full use of a DTC philosophy, and presents a 
low-cost approach to the EOS-A and -A r execution phase. The plan provides the structure 
to manage within program funding, and flexibility to manage within fiscal year funding. 
Also, an early selection of the System Integrator will assist in the Instrument procure- 
ment as well as in optimum planning for the Basic Spacecraft. The development of a 
Basic Spacecraft will also enhance future space programs by providing standard space- 
craft hardware for low-cost space programs. Figure 3-6 presents the EOS program 
development flow. A candidate for separate procurement is the Basic Spacecraft, which 
may be developed earlier and separate from other elements of this EOS program. 

3. 4 CONTRACTING TECHNIQUES BETWEEN THE PRIME CONTRACTORS AND SUB- 
CONTRACTORS 

Our review of subcontracting techniques and the goals of a DTC program has 
resulted in the following specific recommendations for implementation of an effective 
EOS procurement plan. 

Changes are the most frequent cause of cost growth and schedule delays in major sub 
contracts. Changes are often the result of placing a priority on scheduling that appears 
to justify incomplete requirements definition at the time of initial authorization to proceed. 
A significant reduction in change activity can be achieved by delaying major, high-risk 
procurements until the systems engineering effort has provided more precise performance 
and interface requirements; this approach also reduces cost and provides significantly 
more accurate schedule planning. 

Since the seller assumes the highest degree of risk under fixed price contracting, 
flexible type contracting should be minimized. Maximum use of r bff the shelf” com- 
ponents appears to complement this basic policy. In areas where development or 
modification could make the use of fixed price contracting counter-productive in 
terms of program interests, flexible type contracting can be selectively used. Where 
practical, individual subcontract would be segmented to isolate those areas of uncer- 
tainty that lend themselves to flexible pricing and, if necessary, delay contracting 
of later phases until definition is sufficiently clear to permit firm pricing. 
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Similar to the problem regarding changes resulting from lack of complete 
systems engineering and requirements definition at program inception, changes can 
also occur as the result of a precipitous release of the production phase* Production 
should be delayed until development testing provides clear assessment of the final design 
configuration. Special emphasis should be applied to a careful review of produceability and 
manufacturing processes prior to production release. 

In concert with the policy of maximum use of fixed price subcontracting, the speci- 
fications should convey maximum responsibility to the subcontractor. Maximum respon- 
sibility is conveyed by a minimum of detail. One extreme would be to procure equipment 
"suitable for the use intended "by defining "the use intended". Conversely as specific 
design detail and other restrictive requirements are added, the prime contractor assumed 
responsibility for the effect of this detail and creates a scope envelope that is more subject 
to contractual change. However, all critical performance, test and interface parameters 
will be clearly defined. 

Experience shows that seller T s responsibility for the successful performance of his 
equipment can be effectively extended through installation and checkout in the end article. 
This contrasts with the traditional method of basing acceptance upon inspection and test at 
source or incoming inspection at destination. Selected sellers would be contractually ob- 
ligated to provide personnel and equipment to participate in "shepherding" their flight hard- 
ware through spacecraft installation and checkout. 

Another method of providing motivation to selected sellers throughout their sub- 
contract performance will be to provide seller opportunity to earn additional fee based 
upon the performance of seller equipment in orbit. 

Early and continuing emphasis will be applied to produceability. Initial design re- 
views will incorporate specific attention to this discipline to ensure cost effectiveness and 
uniform repeatability of the product. Manufacturing methods and processes will receive 
early attention to provide confidence prior to production release. 

An area of significant cost in major equipment procurements is documentation. 

The traditional approach to documentation has been to pass down to sellers the appli- 
cable portions of prime contract requirements, including format and depth of detail. We 
recommend that documentation requirements for each procurement be "tailored, "taking into 
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account the specific use to which it will be put, quality, and extent of existing data and 
formats currently employed by the seller that may differ from specification requirements. 
Emphasis shall be placed upon the practical needs of the potential users and not on rigid 
conformance to uniform standard requirements. 

Responsibility for monitoring seller adherence to the quality assurance provisions 
of a Grumman subcontract should rest with Grumman. Specifically, acceptance of an end 
product at a seller’s plant should be at the discretion of the Grumman quality assurance 
representative. Providing secondary, overlapping responsibility to Government resident 
quality assurance personnel duplicates effort that adds to the administrative costs of 
the subcontract, provides dual authority for quality assurance decisions and often delays 
critical deliveries. 

Traditionally, payments to sellers under fixed price subcontracts are based upon 
incurred cost (progress payments) or physical delivery of an end item. Neither of these 
methods provide adequate incentive to the seller in meeting the early critical milestones 
that are often not evidenced by physical deliveries, but which are critical to later equipment 
deliveries. By selectively establishing payment schedules based upon achievement of key 
milestones, the sellers are provided with an incentive to stay on schedule early in the 
program. 

If under the subcontract clause of the prime contract, the Government reserves 
the right of prior approval in the placement of specific types of subcontracts, there 
should be a time limit established for this approval cycle. This will permit more precise 
scheduling of the procurement plan and will prevent delays that could ultimately effect 
equipment delivery. A time period of 10 days, after which in the absence of disapproval 
Grumman would be authorized to proceed, would appear reasonable. 

Pooling procurement of critical components that are common to several sub- 
contractor’s equipment has been found beneficial from a cost, schedule, and quality 
viewpoint. In these instances, Grumman and the Government can benefit from the lower 
cost from larger volume procurement, and maintain greater control over uniform quality 
of the parts. However, due to the administrative costs and contractual ramification on 
our subcontract relationship this procedure would be employed on a highly selective basis. 

As part of the evaluation process of all seller proposals a risk analysis will be 
prepared. This analysis will identify specific areas of risk in schedule, cost, and technical 
performance. In instances of competitive procurement, this analysis will become part of 
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the selection criteria. In addition, the analysis will provide the basis for planning the 
procurements in such a way as to minimize program impact. 

To minimize total program cost by maximum use of available Government supplies 
and services, the Government will be considered a potential supplier in areas such as spe- 
cial test equipment, residual flight hardware, engineering services and test facilities. 
Program requirements in these areas will be to ensure taking advantage of opportunities 
that may exist. 

Decisions by the program CCB must be made on the basis of firm economic con- 
sideration. Where changes affect subcontractors, firm subcontract commitment as to 
price must be obtained prior to such decision. Budgetary estimates and lack of firm 
technical definition contribute to unplanned cost growth and poor cost effective decisions. 

3.5 MANUFACTURING 

Manufacturing techniques and procedures recommended for the DTC EOS Program 
to reduce the manufacturing segment of the overall program costs include support of DTC 
activities, maximum build for standard parts, use of a 'limited production" manufacturing 
approach for small quantity parts, and a manufacturing Verification System to increase 
personnel motivation to ’do it right the first time. " 

Manufacturing works closely with Engineering in trading off alternate concepts and 
configurations, and establishing DTC targets for the recommended configuration with the 
aid of a Designer's Cost Manual. As DTC targets are established, a Manufacturing plan 
for fabrication of EOS hardware is developed. At the conclusion of each phase, the 
planning data is projected and documented for the implementation of each succeeding phase. 

In the development phase of the EOS programs manufacture of small quantity parts 
for the EOS program will use a "limited production" manufacturing approach. The low rate 
of manufacture permits use of the 'limited production" approach where in shop technician 
skills and simple shop aids replace most of the formal, detail and subassembly tooling. 

Tools will be provided only when essential to ensure structural integrity, meet production 
requirements, and maintain interface requirements between EOS modules and the EOS 
Launch Vehicle. 

EOS parts are designed to utilize prototype manufacturing techniques, with tolerance 
based on prototype capabilities. Parts fabrication is simplified by producing sheet metal 
and machined parts from full-scale mylar or dimensional engineering drawings. 
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Hydraulic lines are developed from template (soft tubing) lines that have been de- 
veloped and verified on the vehicle to permit use of standard tooling available, and to 
reduce project tooling requirements and associated costs. Electrical wiring will be 
built up by attaching connectors to one end of wiring that has been cut oversize from 
lengths established from engineering drawings. Final routing, bundling, and attach- 
ment of remaining connectors/terminals will be accomplished directly on the vehicle 
during final assembly. This approach has proved to be the most cost-effective on low- 
quantity production programs. 

MANUFACTURING MANAGEMENT SYSTEMS - Electronic data processing (EDP) 
operating systems will be used on the EOS program. The overall systems encompasses 
the capability to control either low-or high-rate production programs. Operating in a 
reduced mode, the Manufacturing Operational Data System (MODS) provides the level of 
accountability required for low-rate/volume EOS type programs without incurring the 
high cost normally associated with major EDP systems. The MODS provides product 
definition in an indented parts list (IPL) and supplies inventory control, part tracking 
through fabrication, and automated work orders, kit lists, and back orders for assembly 
work releasing, MODS also provides tracking for manual (prototype) work orders that 
are released to initiate fabrication of parts „ 

CHANGE CONTROL - Minor changes to the EOS design may be implemented in 
the shop by r ^red line" drawing changes which are made informally, with Engineering and 

Manufacturing management concurrence on budget and schedule impact. The "red line" 
changes are coded on the shop copy and immediately incorporated on the original drawing. 

Engineering Orders (EO's) will be issued for more complex changes, including 
the creation of new parts and/or assemblies. 

MANUFACTURING VERIFICATION SYSTEM - The MVS increases personnel motivation 
to 'do it right the first time". Under this system, technicians are issued personal certifica- 
tion stamps that they use to indicate satisfactory completion and inspection of operations on 
the work order. Items presented for acceptance are verified by a Quality Control inspector 
with subsequent Quality Control inspection, levels increased or decreased in accordance with 
shop performance. 

Performance in the shops is fed back to Manufacturing management for improvement 
and corrective action. The verification system reduces inspection manhours up to 15% 
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in areas under the system, reduces repair/rework activities, and increases the quality 
of completed hardware. 

3.6 TEST PHILOSOPHY 

The total EOS Development, Qualification, Integration add acceptance test program is 
shown in Figure 3-5. The approach shown ties in with the basic EOS test requirements 
and trade studies documented in Report 3, Subsection 6. 18. These studies examine the 
alternative approaches to satisfying both the basic LRM mission and common spacecraft 
test requirements at a cost saving of $1. 8 million. 

3.6.1 RECOMMENDED APPROACH 

• Combining all system and component environmental acceptance tests at 
the module level representing a cost savings of $500 thousand, or 50% 
per Spacecraft of environmental acceptance test costs over the conventional, 
component and system environmental test approach, and at virtually no 
program cost, schedule, or technical risk 

• • Qualification of the basic spacecraft structure and modules for follow-on 

as well as the basic missions, to provide a level of design confidence which 
permits NASA to take advantage of the cost benefits of a multi-buy Spacecraft 
procurement plan. Based on subcontractors estimates for a 30-unit buy versus 
a 5 -unit buy this could represent a 20% cost savings in component costs alone 

• Separate component and module qualification tests to ensure that component 
qualification levels are adequate to cover follow-on mission environment 

• Verification of the flight instrument and ground processing system compatibility 
and functional performance, independent from the basic spacecraft flow, and 
providing both a low cost approach to demonstrating the EOS mission-peculiar 
hardware and software flight readiness as well as maximum Integration and Test 
schedule contingency and flexibility 

• Utilizing the high percentage of developed subsystem avionics hardware to permit 
elimination of a costly bench or laboratory avionics development spacecraft 

• Making the systems qualification spacecraft available for performing Shuttle 
ground and flight EOS on-orbit resupply demonstration, and/or refurbishment 
for flight 

3.6.2 INTEGRATION AND TEST 

BASIC SPACECRAFT - The I & T program for a typical set of EOS light hardware 
is shown in Figure 3-7. The components are functionally tested at the subcontractor and 
shipped to the prime contractor for integration into the modules. Once the modules are 
integrated and functionally checked the modules are subjected to either acoustic or mechan- 
ical vibration, two days of thermal cycling, and a six day thermal vacuum test to verify 
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component and module workmanship. The current plan calls for serial testing of the 
modules using the same Test and Integration (T & I) station and unique software interfacing 
through the module remote decoders and multiplexers. Individual hardwired GSE is used 
for module power and monitoring of hard lines during test. The non-mission, unique 
on-board software will be developed, debugged, and qualified in the software development 
laboratory. Integration of the flight software with the flight computer will be accomplished 
during integration of the CDH module. Initial software required for the ACS processing 
during ACS module tests will be simulated from the T&I station. 

Upon completion- of the module level tests the subsystem modules will be integrated 
together, and functionalty checked as a system on the flight Spacecraft back-end. At this 
point, we have a Basic Spacecraft reac^y for integration of the mission peculiar Instruments, 
Instrument module, mission software, and Orbit Adjust/Reaction control system module. 

MISSION PECULIARS - The Instrument, IMP and Wideband antenna will be tested 
as a system at GSFC, using the IMS Primary Ground Station to demonstrate the flight and 
ground system compatibility, and prior to integration of the Instrument with basic spacecraft. 
Observatory/Control Center and Network compatibility will be demonstrated via RF 
through the WTR ground station. 

Integration of the mission peculiars could directly follow the Basic Spacecraft 
buildup as shown in Figure 3-7, or be downstream with the Spacecraft held in controlled 
environment storage facilities. In the typical flow and schedule shown, the next step 
would be to integrate the mission peculiar hardware and software, and perform observatory 
level systems performance tests, including EMC. The separation and solar array deployment 
mechanisms are then tested. The solar array size, and potentially its deployment 
technique, is mission peculiar; therefore, it is performed at this point in the schedule. 

The separation test, however, could be performed earlier /but it is performed here as 
a matter of convenience. Prior to shipment of the observatory of WTR for launch, a 
workmanship acoustic test of the integrated observatory is shown. The observatory, 
in flight configuration with the exception of pyrotechnics, will be transported to WTR 
in the horizontal position. WTR prelaunch operations are scheduled for five to six weeks 
as a target since no extraordinary tasks or special tests are required at the launch site. 
Shuttle, Titan, and Delta launch vehicle flows all permit observatory integration 
with the launch vehicle about 7 to 10 days prior to launch. 
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3.6.3 DEVELOPMENT AND QUALIFICATION TEST 

The recommended Development and Qualification test program for the EOS flight 
hardware is shown in Fig 0 3-8. Since it is a design goal to accommodate all missions 
with the same Basic Spacecraft, the recommended test program considers the basic EOS 
land resources mission configuration qualification as well as qualification of the Basic 
Spacecraft for follow on missions. 

The recommended plan provides for module, thermal development and structural 
qualification testing at the module level. The thermal development tests are required 
on at least two of the subsystem modules to verify the thermal analysis model. Acoustic 
and mechanical vibration qualification tests are performed at the module level for two 
reasons: to determine component environments seen during module tests so as to 
evaluate module level acceptance test methods, and to qualify the basic module structure. 
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3.6.4 SPACECRAFT 

The same modules used for module level tests with the component mass represen- 
tations installed will be used for vehicle level tests. The LRM OAS and IMP module 
configuration will be used for Observatory Structural Qualification. OAS/RCS IMP 
modules for follow on missions will be qualified where required at the module level. 

The program requirements of Report 3, Appendix C call for vehicle static tests to verify 
structural loads; however, based on the trades studies documented in Report 3, Subsec- 
tion 6.18, a vehicle level acceleration is recommended as a more cost effective approach 
to verifying the module and spacecraft static strength. An early acoustic and mechanical 
vibration test is recommended for both the LRM and follow on configuration for two 
reasons; 

• Provide early verification of component environmental levels to preclude down 
stream requal 

• Permit an early evaluation of the total spacecraft environments vs the design 
environment for the various configurations . 

The Observatory model survey is required for the cantilevered and free-free 
configuration for both the LRM and follow on configuration. 

MECHANISMS - Qualification of the separation, and deployment mechanism as 
well as the basic LRM solar panel structural design is achieved during the observatory 
level qualification tests. Earlier in the program off line development tests of the mech- 
anisms will be required to verify the basic design approach. 

ANTENNA PATTERNS - S-Band, X-Band, and DCS antenna pattern tests are sched- 
uled early after contract go-ahead to finalize antenna locations, and verify link analysis 
for the LRM configuration. These models should be maintained to verify follow-on 
mission antenna patterns. 

OBSERVATORY SYSTEMS - Following the structural qualification the vehicle is re- 
configured for Observatory Systems Qualification, including a qualification model LRM 
instrument consisting of EMC, Acoustic, Thermal Vacuum, RFI and pyrotechnic shock 
test. Vendor qualification components where available or a flight component are required 
for observatory level system qualification. Three and one-half months of S/S module 
integration is allowed for in the schedule to cover first- time integration of the subsystems. 
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Since paralled integration of the modules can be performed by time-sharing the T&I 
station 9 this should be adequate to debug the Basic Spacecraft subsystems and test pro- 
cedures. 

Completion of system qualification tests permit the qualification components to be 
refurbished for flight, or utilization of the entire qualification vehicle for the demonstra- 
tion of shuttle resupply concepts in both ground and shuttle flight test. 

INSTRUMENT INTERFACES - A Spacecraft simulator and the mission peculiar IMP 
module will be required to support instrument manufacturers for functional interface 
verification during instrument qualification and acceptance tests. 

3. 6. 5 GROUND SYSTEMS AND INSTRUMENTS 

Figure 3-9 shows the Ground System hardware and software flow for both the DMS 
and Mission Operations Control Center. 
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INSTRUMENT DATA ACQUISITION - Instrument Data Acquisition during Observatory 
Qualification and Acceptance tests will be accomplished via a low-cost Ground Station 
front-end, which will be part of the T&I station. Observatory test tapes willlbe provided 
to validate Low Cost Ground Station field site installations. Primary ground station- 
observatory compatibility tests can be demonstrated by, testing the Instrument - IMP 
and spacecraft simulator setup at GSFC prior to integration of the instrument with the 
flight spacecraft, or by shipping the entire observatory to GSFC prior to de lively for 
WTR for launch. The cycling of the Instrument, IMP and Spacecraft simulator through 
GSFC was chosen since the total Instrument data train including RF is checked at minimum 
cost without tying up the entire T&I crew and observatory. During Observatory Systems 
Tests, Instrument performance will be evaluated by internal instrument calibration 

monitoring at the T&I station, for both wide-band full data-rate operations and the Low 
Cost Ground Station lower data-rate. 

CONTROL CENTER - Control Center check out and personnel simulations training is 
recommended to be accomplished by software simulation because it provides both maxi- 
mum flexibility in schedule and follow on mission reconfiguration at minimum cost. 

3.7 RELIABILITY AND QUALITY ASSURANCE 

The following approach is recommended to ensure the required reliability at the 
lowest cost. The Reliability Program plan will be a single document including the site 
plans; it would be updated as required by major changes, rather than undergo periodic 
updating. Program control and progress reports would be integrated into the design re- 
views. Formal reporting would be limited to significant events and problem areas. Design 
specifications will be prepared for each item of hardware at the system, subsystem, and 
component level. 

Reliability predictions will be performed as necessary to support trade studies, 
maintainability analysis, and logistics planning. Updates will not be required for minor 
design changes, and predictions will not be to detailed levels within black boxes. Complex 
models internal to black boxes are expensive and are of questionable value. 

FMEA*s will be performed within the black boxes for all critical functions and to 
the piece part level for hazardous and mission criticality failure modes only. Program 
failure reporting and correction will be in accordance with contractor procedures. 
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Additional recommendations are to include launch critical GSE in failure reporting 
system and selectively include other GSE. Implement a system to standardize design and 
fabrication processes and standardize parts. Test requirements are recommended in the 
test philosophy section. 

The recommendations for Quality Assurance are: 

• Test and inspection verification by Government inspection agency to be on a 
post-audit basis to reduce cost and eliminate delay. Post-audit permits the 
contractor to move ahead in the manufacturing/test cycle and monitored by the 
Government Representative 

• Determine traceability requirements on basis of need. Distinguish between 
Critical Structural Items, Limited Life/Cycle Items, Matched Items requiring 
replacement in pairs, and routine less- complex items 

• Introduce a material review system tailored to the significance of defect and 
item criticality. Delegate responsibility to a single authority. QA will imple- 
ment corrective action. Government representative will exercise jurisdiction 
on post-audit basis. 

The contractor should select workmanship standards and will be subject to continuing 
NASA review. 

3. 8 DOCUMENTATION AND CONTROLS 

The low-cost management techniques for documentation and controls will provide 
NASA with visibility of EOS progress and enhance mutual confidence without excessive 
documentation and control. The recommendations will provide NASA with all of the basic 
information it needs to measure and guide program performance, while simplifying and 
reducing the correlated cost of documentation review, ordering, delivery, storage and 
retrieval, specification requirements, configuration baselining, and change control. Our 
recommended use of the System Integrator team will reduce formal documentation to a 
minimum and increase visibility to a maximum, with the resulting savings of approximately 
$1.25 million. 

Our recommendations are summarized under the following categories: Documenta- 
tion Requirements, Requirements Specifications, Baseline and Change Controls. 

The first topic is the methodology of establishing the requirements for documenta- 
tion in the first place, Subsection 3. 8, 1, "Requirements Establishment and Ordering 

Techniques". The second topic is Subsection 3.8.2, "Documentation Formats and Man- 
agement Systems Requirements" and finally, Subsection 3.8, ’Documentation Process- 
ing and Review". 
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3. 8.1 REQUIREMENTS ESTABLISHMENT AND ORDERING TECHNIQUES 

The following recommendations address the area of documentation requirements 
establishment and ordering techniques': 

• Limit the documentation ordered at contract award to the unique legally (procure- 
ment regulation) mandated items, the key documents obviously required for 
approval by NASA, and an accession list of all other data prepared by the 
Contractor as a by-product of his work scope 

• Conduct review and "tailoring” of documentation requirements such as financial 
reports, to the specific program needs after contractor selection and before 
finalization of the contract when the Contractor is free from the pressure of 
competition and the NASA is freed from the requirement to keep things equal 
between competitors. 

• In lieu of requirements, provide a Government/Contractor review of documenta- 
tion requirements concurrent with the technical design review process to scrub 
and revise the contract requirements as the program unfolds. Use an approach 
wherein items that are "now apparently" not needed can be eliminated, and the 
need for contingency items can be determined with greater accuracy. 

• Encourage "data minimization" by providing flexibility within NASA as well as 
the Contractor, for reduction of formal documentation in lieu of other means 
of acquiring equivalent information. 

3. 8.2 DOCUMENTATION FORMATS AND MANAGEMENT SYSTEM REQUIREMENTS 

One reason that documentation costs are typically high is because of the expenditure 
of resources to formalize reports, test data, specifications, procedures, manuals, and 
plans. Documentation costs are incurred both directly and indirectly. The costs directly 
associated with providing specified data, such as the in-house identification and validation 
functions, are relatively obvious. Less obvious are the costs associated with require- 
ments to comply with the multitude of management information and control systems which 
may be required indirectly to satisfy individual data requirements. 

We recommend that the rigidity of format be considerably relaxed. Data require- 
ments should reflect the minimum acceptable documentation that will supply the user with 
the depth and content of the information he needs. The Contractor should be able to 
satisfy most of the requirements with information that is a normal output of the manage- 
ment/design/development/production effort, using generally good business practices. 
Face-to-face verbal discussion promotes the mutual trust, respect, and teamwork that 
is essential to achieve EOS program objectives. 
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There are a number of areas where rigid format requirements can be relaxed with 
no adverse affect on the contract performance, end product use, or supportability. One 
area is the engineering drawing requirements. 

Another area loosely falling under the category of format is the storage and retrieval 
functions of documentation management and the media of transmittal. 

Emphasis should be placed on maximum use of contractor format whenever it can 
fulfill the "intent” of the documentation or system requirement of the Government. 

Documentation requirements should take into considei'ation the regular review, 
monthly status meetings, etc, which take place as a forum for transmitting the needed 
information, rather than via formal reports. Minutes of such meetings could supplement 
many "data items ". 

Utilize informal working documentation - the same material that the Contractor's 
engineers used to make their decisions - in lieu of formal reports. Some examples of 
this information might be engineers notebooks, engineering layouts, and raw data sheets. 
Good data need not be "pretty" to do the job, and NASA personnel are technically 

competent to review the same data and make their conclusions in an "over-the-shoulder" 
or "on-the-board" environment. 

Specify engineering drawings to industry standards, or at the very most, Form II 
Drawings to Industry Standards. The following modifications to normal drawings 
practices are recommended: 

• Use of Engineering layouts in lieu of formal assembly and installation drawings 

• Elimination of margins and zones on engineering layouts 

• Eliminating rivet length callout on drawings for rivets which measure less 
than 1 in. long 

• Less restrictive reproducibility requirements for paper copies - allowing 
full legibility of first generation copies in lieu of fourth generation. 

Replace conventional hard copy transmittal of documentation, wherever practicable, 
with microfiche. This recommendation is particularly applicable in conjunction with the 
deferred ordering or accessioning of documentation. 
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Do not implement requirements for more Quality Assurance imposed on documenta- 
tion, and do not require DD-250 , s (or equivalent) for documentation. The recommended 
direction is to reduce not increase this type of requirement. 

3. 8.3 DOCUMENTATION PROCESSING AND REVIEW 

The documentation processing and review recommendations are: 

• All contractual data/documentation requirements should be carefully screened 
by NASA prior to imposition on the contractor to assure that documentation 
that does not directly affect NASA ! s interests, or has a higher level require- 
ment controlling it, be submitted for information rather than for approval. 

• Only design concept drawings be specifically signed and approved by NASA. 
Manufacturing drawings should not require Government Representative signa- 
ture; such signature does not connote approval, and does not relieve the Con- 
tractor of his overall responsibilities. 

3.9 REQUIREMENTS SPECIFICATION 

For a given procurement, be it NASA procuring from a contractor, or a contractor 
purchasing from a subcontractor, the way that the requirements for the item being 
purchased are specified can have a dramatic impact on the cost of the item. The cost 
can be incurred to a greater or lesser degree dependent upon the choice of the type of 
specification, the matching of the content to the specification function, and the level of 
customer involvement and approval. 

In addition to these factors, there are, of course, savings that can be realized by 
intelligent specification preparation practices which minimize the cost of maintaining the 
documents as changes occur. 

For our recommendation, we have focused on the following specifications: 

• Development Specifications - Define the T, design-to” requirements for an item 
to be developed. The essence of this type of specification is the items per- 
formance, form factor and other pertinent technical considerations 

• Product Specifications - In addition to the performance and design requirements, 
these specifications define the ,T build to” and M fcest-to ,T requirements. They may 
be part II of a two-part specification, the first part of which is the Development 
Specification 

• Materials and Process Specifications - State the requirements for materials and 
techniques and procedural requirements applicable to materials or fabrication 
processes. These are subsiduary specifications which are referred to in the 
higher-tier specifications, or on the implementing engineering drawings. Test 
specifications are included in this category. 
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Our recommendations related to specification- type and content are presented in 
the paragraphs that follow. 

Whenever possible, utilize Functional Specifications stating performance only as 
opposed to Detailed Design Requirements in accordance with the following guidelines: 

• Use Development (Design Control) Specifications for any item below the system 
level whenever it is considered sufficient to specify performance only (as 
opposed to fabrication) 

• Limit use of Design Control Specifications to those items where it is necessary 
to specify performance as a first step in developing a Product Fabrication (detail 
design) Specification* (The transition to a fabrication specification is greatly 
iacilitated by the existence of a Development (Design Control) Specification.) 

Performance requirements should be stated in quantitative terms only, that is, in 
terms of numerical inputs and outputs including permissible tolerances under various 
operating conditions as applicable. This is the only way performance values and toler- 
ances can be established and verified for use in the attendant test or checkout procedure. 
In the case of the specification defining the preproduction configuration, these values 
and their tolerances serve as the basis for establishing the performance criteria of the 
equipment under the various environmental conditions of the qualification test. 

Any development specification should be void of "how-to" design details. Such 
details will only inhibit the designer's function by telling him how to do something instead 
of stating the end result he is required to achieve. This type of information belongs in 
the fabrication specification. The development specification should not contain philosophy 
and descriptive matter; rather, it should devote itself to exact statements based on a 
black-box concept (that is, list only inputs, outputs, and interfaces without concern for 
principles of operation). One exception would be when, for a valid technical reason, part 
of all of the detail design has to be dictated. In general, specification of design details 
should be kept to a minimum. 

Product Fabrication (detail design) Specif! cations are applicable to any item below 
the system level (including computer hardware), and are oriented toward procurement of 
a product through specification of primarily fabrication (detail design) requirements. 

This specification should be used for second source procurement or re -procurement (that 
is, when it is necessary to make available a design disclosure package) to control the 
interchangeability of lower-level components and parts, and when service, maintenance, 
and training are significant factors. This specification shall state: 
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• A detailed description of the parts and assemblies of the product, usually by 
prescribing compliance with a set of drawings 

• Those performance requirements and corresponding tests and inspections nec- 
essary to assure proper fabrication, adjustment, and assembly techniques. 

In instances where a Development (Design Control) Specification has been prepared, 
specific reference to the document containing the performance requirements for the item 
shall be made in the fabrication specification. Tests normally are limited to acceptance 
tests in the shop environment consisting of selected performance requirements and ver- 
ifying tests. Preproduction- type or periodic tests to be performed on a sampling basis 
and requiring service or other environment may reference the associated development 
specification. 

Eliminate "how-to" information from process specifications, leave the methodology 
to the selection of the subcontractor. Whenever possible, reference broader NASA docu- 
ments in lieu of contractor process fabrication. 

A contractor process specification is required only when the customer specification 
covering the applicable requirements is not detailed enough for the required process 
control. The process specification is essentially a general specification; it is, therefore, 
applicable only to the extent specified on the design drawing or in the equipment specifi- 
cation. Manufacturing or process specifications should not be referenced to the point of 
inhibiting manufacturing technology or initiative. By imposing detailed specifications on 
sellers, for instance, the seller may be forced to depart from his normal methods with 
no actual improvement in the end result. The emphasis always should be on design 
conformance, not methodology, keeping in mind that the purpose of a drawing upon 
which the process specification is referenced is not to control production; rather, it is 
to control the design configuration and to present the criteria for determining whether 
the item conforms to the stated requirements. 

Restrict the content of Preinstallation (Bench) Test Specifications wherever possible 
to functional electrical and mechanical checkout instead of duplicating acceptance tests. 
This practice will reduce actual test time as well as specification preparation and main- 
tenance time. 
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Request the subcontractor to propose Verification (Test) Methods appropriate to 
the type of equipment instaed of specifying them to him in detail. This procedure, par- 
ticularly in the DTC environment, has several advantages. It enables the seller to 
exercise his initiative, and it provides alternatives for the buyer when dealing with 
several sellers in a competitive environment. 

Encourage the reduction of testing, assessment, and analysis when advantage can 
be taken of previous work of a similar nature. 

Eliminate or greatly reduce, whenever feasible, general requirements or specifica- 
tions for such things as Human Factors, Safety, Reliability, Maintainability, etc. Instead, 
substitute broader functional requirements that give the seller flexibility in demonstrating 
that he meets them. This approach will also reduce specification maintenance cost. 

A general specification covers requirements common to two or more types, classes, 
grades, or styles of products, services, or materials. It avoids repetition of common 
requirements in other specifications. It also permits changes to common requirements 
to be readily effected. General specifications may also be used to cover common require- 
ments for weapon systems and subsystems, such as reliability, maintainability, human 
factors, weight control programs, etc, as well as sealing, watertightness, and certain 
finish requirements. 

One of the most important things to remember about general specifications imposed 
on sellers is that the temptation to re-organize the seller T s house must be resisted. In 
most cases, the sellers are capable of complying with general requirements imposed on 
them. As a rule, it is far more economical to be general enough to enable the seller to 
use his own detailed organizational setups and methods as long as he meets the end 
requirements. To require the seller to do everything the buyers way can be phenomenally 

costly. In addition, the use of general specifications require extreme care in the following 
areas: 

• Whenever reference is made to general specifications in equipment or other 
specifications, such reference should be made by specific paragraph number. 
Theoretically, it is true that if you say "welding shall be in accordance with 
SPG024", it is intended that the seller comply with whatever paragraph of that 
specification deals with welding. He usually suspects, however, that the welding 
requirements maybe scattered (and, unfortunately, he is usually right). Thus 
he hangs a high price tag on the item to cover the requirements that he hasn*t 
found yet. Obviously, requirements traceability is greatly aided by referencing 
specific paragraph numbers. 
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• Unless general specifications are carefully written, it becomes difficult to 
separate a technical task from its associated data task. If for some reason 
the two tasks are not properly separated, a down stream economy measure to, 
say, eliminate the data requirement may result in elimination of both" tasks 
without intending to do so, For instance, a general reliability specification 
may contain a paragraph with the heading "3.2.1 Failure Analysis Report". If 
both technical and the associated data requirements are stated in this paragraph, 
elimination of the report requirement from the purchase order would automatically 
eliminate the technical task of conducting failure analysis as well as the report. 

To avoid this problem, the two requirements must be separated as follows: 

"3. 2. 1 Failure Analysis " 

"3.2.2 Failure Analysis Report. 

3.10 CUSTOMER APPROVAL LEVELS 

The following discussion of the appropriate level of approval of specifications follows 
in general, the arguments advanced previously relative to lands of specifications. Recog- 
nizing that the degree of customer involvement in the affairs of a contractor is related to 
the degree of risk that the Government can accept, we do not advocate reduction of Gov- 
ernment cognizance over areas in which his interest is involved. Rather, our recom- 
mendations deal with the review and approval of specification requirements which are a 
level below those which protect the Government’s interest. 

The specifications at the subsystem level contain all of the performance require- 
ments necessary for Government approval; the Government will accept or reject the 
contractor’s delivered items on this basis. There is little to be gained by Government 
approval of specifications below this level. Surveillance and visibility can still be re- 
tained, but the time -delaying repetitive effort in reviewing and approving iterating re- 
quirements allocated to these lower levels can be eliminated. Government participation 
in activities such as the contractor’s configuration reviews and audits of his sellers can 
provide a more meaningful barometer of design progress and requirements compliance. 

Limit customer approval to system/subsystem level, with contractor control on 
the black-box (equipment) specification level. This will provide greater flexibility 
and timeliness in contractor- sub contract or relations, and will contribute to lower costs. 
System and subsystem level specifications should contain only top-level performance and 
interface requirements; lower tier documents are selectively more detailed. 

3.11 BASELINES AND CONFIGURATION CONTROL 

Our recommended approach for the EOS program is addresses configuration base- 
lining and configuration control. 


, 3-35 



4 


For optimum baseline, the recommendations for the establishment of the product 
baseline are: Select the point in the program for establishment of the product baseline, 
at or near the point of design stabilization to avoid an unnecessary and burdensome change 
mill. Dependent upon overall program schedule, portions of the system should be base- 
lined independently at an optimum point for that segment. 

Since the program schedule itself is the prime cost driver in the change control 
process, the program must be properly paced with regard to development effort and 
design stabilization. This will be done by the System Integrator, 

The System Integrator team will review, discuss and expedite change processing. 
The team will screen potential changes prior to the commitment of them to proposal 
preparation to determine if the contractor should proceed with further effort. Conference 
calls between NASA /Goddard and EOS contractor program managers, with supporting 
personnel in attendance at either end of the conversation, can be ulitized to minimize 
travel and expedite change action. 

While rigorous documentation of changes is necessary, we believe that an Engineer- 
ing Change Proposal format that is the same as the paperwork used internally for change 
processing can be utilized by the NASA. This format will be specifically tailored to the 
EOS program and mutually agreed upon. 

In the DTC environment, the System Integrator will find changes which reduce 
cost to counterbalance proposed changes which increase cost. Cost versus performance 
and requirement tradeoffs will be made continuously throughout the program. 

Mutual confidence results from the identification and visibility of, and prompt 
solution to, problems. NASA/Goddard knowledge that the contractor is not hiding prob- 
lems, rather, his is solving them, as evidenced in the S. I. recommendations, will 
enhance this confidence and make excessive documentation and controls unnecessary. 

3.12 MAINTENANCE OF COMMONALITY 

One of the objectives of our study has been to provide a General Purpose Spacecraft 
which can accommodate a variety of follow-on missions. This philosophy is carried 
through to all aspects of the recommended hardware design, management approach, pro- 
curement plan and test philosophy. 
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The Basic Spacecraft design is flexible enough to support the LRM, Marine Re- 
sources, Ocean Dynamics, Weather Observation and Transient Environmental phenomena. 
The recommended management approach provides a concept of a Systems Integrator which 
maintains a nucleus of people supplemented by the various team elements dependent on the 
emphasis of integration difficulty. The Basic Spacecraft contractor participation on the 
System Integration team assures the continuity of experience, test, and checkout proce- 
dures and techniques, GSE, from mission to mission. 

Our recommended procurement plan coupled with our test philosophy is designed 
to provide for maintenance of commonality as well as incorporation of technology advances 
without destroying commonality and interchangeability of the Basic Spacecraft approach. 
The procurement plan essentially is designed to make the Basic Spacecraft a "MIL STD" 
part, with first procurements involving the Basic Spacecraft design development, and 
standard set of specifications for the EOS A and A f mission. Once the Basic Spacecraft 
design is qualified and proven, the Government then has a Basic Spacecraft with proven 
capability, and can then proceed to procure an inventory of spacecraft as funding becomes 
available. Our test philosophy of qualifying at the component level, qualifying the Basic 
Spacecraft to design limits, and acceptance testing of the Basic Spacecraft and modules 
separately, allows technology changes to be incorporated, and out of production components 
or piece parts to be incorporated within the "MIL STD" module specification with no total 
Basic Spacecraft impact of equal requirements. 

Our recommendation, therefore, is to select a design, management approach, pro- 
curement plan, and test philosophy which in themselves support the basic objective of 
maintaining commonality to reduce the cost of future spacecraft programs. 
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4 - MANAGEMENT APPROACH ALTERNATIVES 

4.1 CONTRACTING TECHNIQUES BETWEEN THE GOVERNMENT AND THE PRIME 
CONTRACTOR 

To compare the alternate contracting techniques for the EOS program, the major 
elements of the program are identified as follows: 

Instruments, Basic Spacecraft, Mission 
Peculiar Spacecraft, Control Center and 
Mission Controls, Central Data Process- 
ing Facility, Low Cost Ground Station, 

Launch Vehicle, Shroud, FSS, ME MS and 
the Data Acquisition Station. 

These elements may be procured either individually or by a single procurement and 
several alternates are discussed. For the purpose of presenting these alternatives, the 
Launch Vehicle, Shroud, FSS, MEMS and the Data Acquisition Station are deleted, as they 
tend to be procurements uniquely handled by the Government. 

The first alternative is for NASA/Goddard to procure, through a single procurement, 
the elements shown below: 

Instruments 
Basic Spacecraft 
Mission Peculiar Spacecraft 
Control Center & Mission Controls 
Central Data Processing Facility 
Low Cost Ground Station 

This approach is preferable for systems development as the responsibility for the 
total program rests with a single contractor. A single procurement reduces the cost in- 
curred by the Government and Industry for the competition and administration of the con- 
tract. As each px’ocurement has an associated cost incurred by the Government and the 
contractors, the cost associated with a procurement is minimum in this approach. 

The highest risk element in the EOS program is the Instruments which require de- 
velopment. For the System Integrator to contractually assume the contractual and techni- 
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cal risk associated with this procurement would add around 30% to the procurement costs 
of the Instruments. 

Therefore a second alternative is for the Government to contract 
directly for the EOS Instruments and supply them to the System Inte- 
grator as GFE with the System Integrator procuring the remaining elements. 

NASA /Goddard 


INSTRUMENTS 


SYSTEM INTEGRATOR 


Thermal Mapper 

HR PI 

PM MR 

SAR 

SEOS 

Solar Maximum 
Data Collection System 
SEA SAT 
MSS 


Basic Spacecraft 
Mission Peculiar Spacecraft 
Control Center & Mission Controls 
Central Data Processing Facility 
Low Cost Ground Station 


This approach separates the high risk elements and distributes the risk between the 
Government and the Contractor. The 30% increase in Instrument cost associated with this 
risk in our first alternative is eliminated. 

As this approach increases the number of procurements, those costs associated with 
the procurement and contract administration are increased. As this cost involves Govern- 
ment cost and Contractor cost, the value is not easily determined but it could be as little 
as 5% or as much as 20%. In any event it appears to present a lower cost program than the 
first alternative. 

A third alternative has Goddard procuring the Basic Spacecraft, Control Center and 
Mission Control with a single procurement and supplied to the System Integrator as GFE, 

NASA /Goddard 

SYSTEM INTEGRATOR 
Basic Spacecraft Instruments 

Control Center & Central Data Processing Facility 

Mission Control Low Cost Ground Station 

Mission Peculiar Spacecraft 
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This approach has the advantage of developing the Basic Spacecraft early if funds are 
not available for total program funding. The System Integrator has the Instruments as a 
cost driver which will increase their cost by around 30%. The multiple procurement will 
also add 5% to 20% to the Basic Spacecraft. 

The fourth alternative is to procure the Central Data Processing Facility and Low 

< 

Cost Ground Station separate from the System Integrator effort as follows: 

NASA/Goddard 

SYSTEM INTEGRATOR 

Central Data Processing Facility Instruments 

Low Cost Ground Station Basic Spacecraft 

Mission Peculiar Spacecraft 
Control Center & Mission Controls 

The system responsibility for the Spacecraft and Instruments rests with a single con- 
tractor and is beneficial for Satellite development; however, the increased costs for the 
Instrument risks and the multiple procurement is about the same as for alternate three. 

The fifth alternative is to have three procurements as follows: 

NASA/Goddard 

SYSTEM INTEGRATOR 

Instruments Basic Spacecraft Central Data Processing 

Mission Peculiar Spacecraft Facility 

Control Center & Mission Control T ~ 

Low Cost Ground Station 

This approach groups like procurements together and isolates the high risk and low 
risks elements of the program. If 5% of the procurement costs is valid for multiple pro- 
curements, this approach may be the lowest cost approach. However, if procurement re- 
lated costs, contract administration and interface costs are 10% or more, this approach 
could well be the most expensive. 

As the costs of multiple contracts are not accurately predicted since no good data is 
available, this comparison is not exact; however, it is believed that they are within reason- 
able tolerances and valid for a comparison of the above alternates. Therefore from a cost 
viewpoint, the second alternate appears to be the most favorable for the EOS Program. 
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4.2 CONTRACT TYPES 

The contract types available are: Cost Type, Fixed Price and Time and Material or 
Labor Type contracts. The cost type may have a fixed fee, incentive fee, award fee or 
some combination. Fixed price contracts may be firm fixed price or fixed price incentive. 
Other variations are available but add little to tills discussion. Some concerns in selecting 

contract type are; whether the procurement fits the contract type, will the contract type 
achieve the desired results and will the administration be excessive. 

The possibilities of either cost type or fixed price for the design and development 
and follow on is shown on Table 4-1. These initial possibilities are based on the technical 
advancement of each element and follow-on procurement after development. 

The cost type fixed fee contract has only normal administrative problems and is 
simple but has not been accepted as a cost effective method. 


Table 4-1 Contract Types 


INSTRUMENT/EQUIPMENT/ 
FUNCTIONAL GROUP 

CPFF 

CPIF 

CPIF/AF 

FPI 

FP 

T&M 

THERMAL MAPPER 

X 

X 

X 




HR PI 

X 

X 

X 




PMMR 

X 

X 

X 




SAR 

X 

X 

x 




SEOS 

X 

X 

X 




SOLAR MAXIMUM 

X 

X 

X 




DATA COLLECTION SYSTEM 




X 

X 


SEASAT 



' 

X 

X 


MSS 




X 

X 


BASIC SPACECRAFT & MODULES 

X 

X 

X 

0 

0 


CONTROL CENTER 

X 

X 

X 




MISSION CONTROL 






xo 

MISSION PECULIAR SPACECRAFT 

X 

X 

X 




CENTRAL DATA PROCESSING FACILITY 

X 

X 

X 




LOW COST GROUND STATION 

X 

X 

X 

0 

0 



KEY: 

X D&D PHASE 
O FOLLOW-ON 


4T-3 

The incentive contracts are aimed at adding incentives to the contractor. It may or 
may not add incentive to the project people or it may cause program perturbations that are 
not good for the overall program. The award fee adds some direct incentive to the project 
people but also may be counterproductive because of its subjective nature. Administration 
may be quite high. 
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Cost Incentives which are applicable to the EOS, System Integrator approach cover 
three areas; the total program, the development phase and the production phase. An in- 
centive may be provided for the system integration effort and a separate incentive for the 
basic system development* An incentive program which would add emphasis to the produc- 
tion phase of the basic spacecraft and modules is to establish a design-to-cost goal for the 
production unit. The design -to-cost target would be used during the development stage and 
the performance would be measured by the cost of the production units. 

In the selection of incentives, the potential trade-offs which may be required during 
the development must be considered in order that the incentive gains or losses do not jeop- 
ardize the trade-off considered. ' 

4.3 SUBCONTRACT MANAGEMENT TECHNIQUES 

The basic and alternative techniques for subcontracting are shown on Table 4-2 with 
the recommended approach printed in italics. 

SUBCONTRACTING TECHNIQUES FOR THE ECS MODULES 

The alternate methods of modular development are addressed for the development 
phase and production phase. The development may be done by the prime contractor from 
seller components and inhouse components or by the component supplier who has the bulk of 
the jnodule hardware having systems responsibility. 

From data received for the EOS, ACS module, the approximate cost of Systems pro- 
curement is $7,500,000 if procured as a new system. If the Systems Engineering and fabri- 
cation is done at the prime contractor, costs are about $6,500,000. 

In this instance a further reduction of approximately $1, 000,000 in cost resulted from 
selecting alternate components which meet the EOS performance requirements for a lesser 
cost. The advantage is in being able to select components from a wide range of suppliers 
and performing the design, integration and test by the prime contractor. 

In the production of the ACS modules for the EOS the recurring cost is about the same 
for either prime contractor or subcontractor production. 

The development by the prime contractor, using state of the art components, has a 
further advantage of focusing the development cost of modules in a single source, thereby 
gaining maximum use of experience and techniques required for the development of modules. 

For the EOS program, consideration should be given to singular module development 
early in the program if funding is not available for Basic Spacecraft development. 
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Table 4-2 EOS Subcontract Management Techniques 


“ 

. SUBJECT 

BASIC TECHNIQUES 

(1 ) SUBSYSTEM & COMPONENT 
PROCUR EM ENT/SYSTEM 
ENGINEERING 

• UNDER THE PRESSURE OF INITIAL SCHEOULE 
PLANNING, PROCUREMENT IS OFTEN INITIATED 
PRIOR TO FINALIZATION OF SYSTEM DESIGN 

(21 CONTRACT TYPE 

• WHERE DEVELOPMENT IS REQUIRED FLEXIBLE 
TYPE CONTRACTING IS USED FOR THE ENTIRE 
PROCUREMENT ' PACKAGE' 

(3) PRODUCTION RELEASE 

• DUE TO SCHEDULE DEMANDS SUBCONTRACT 
PLANNING OFTEN REFLECTS COMMITMENT OF 
RESOURCES TO MANUFACTURE OF PRODUCTION 
EQUIPMENT PRIOR TO COMPLETION OF DESIGN 
& QUALIFICATION 

(4) SPECIFICATION FORMAT 

• PROCUREMENT SPECIFICATIONS CONTAIN HIGH 
DEGREE OF DESIGN DETAIL 

(5) HARDWARE ACCEPTANCE 

• HARDWARE ACCEPTANCE BASED UPON INSPECTION 
& TEST UNIT AT SOURCE &/OR DESTINATION 

(6) FEE INCENTIVES 

* INCENTIVES WHERE USED NORMALLY APPLIED 
TO COST, SCHEDULE &/OR FACTORY TESTING 

(7) PRODUCEABILITY 

• NO CLEAR PRODUCEABILITY REQUIREMENTS 
DURING DESIGN 6 QUALIFICATION PHASE 

(81 OPTION PRICING 

• NEGOTIATE FOLLOW-ON PRODUCTION AS 
NEW PROCUREMENTS 

(9) DATA REQUIREMENTS 

• PROCURE DATA IN ACCORDANCE WITH UNIFORM 
STANDARD REQUIREMENTS 

110) QUALITY ASSURANCE 

® SURVEILLANCE OF SELLER CONDUCTED BY 
BOTH GRUMMAN & GOVERNMENT AGENCY 

(11) PAYMENTS 

o SELLERS SEEKING FINANCIAL RELIEF UNDER 
FIXED PRICE CONTRACTING NORMALLY 
RECEIVE PROGRESS PAYMENTS 

(121 APPROVAL OF SUBCONTRACTS 

• PRIME CONTRACT DOES NOT SPECIFY TIME 
LIMITATION ON APPROVAL CYCLE 

(13) PROCUREMENT OF CRITICAL 
COMPONENTS 

• EACH SELLER BUYS SEPARATELY EVEN THOUGH 
CRITICAL COMPONENTS MAY 66 COMMON TO 
SEVERAL EQUIPMENTS 

(14! QUALIFICATION UNITS 

• DELIVERED AS RESIDUAL MATERIAL AT CON 
TRACT COMPLETION 

(15) RISK ANALYSIS 

• COST, SCHEDULE, AND TECHNICAL RISK ARE 
CO-MINGLED WITH OTHER FACTORS IN THE 
PRE AWARD EVALUATION 

( !6) GOVERNMENT FURNISHED 
EQUIPMENT & SERVICES 

* GEE LIST DEFINED AND PROVIDED IN PRIME 
CONTRACT 

(171 CHANGES 

• ORDERED ON "FLY NOW. PAY LATER" BASIS 
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ALTERNATE TECHNIQUES 

• DELA Y KEY HIGH RISK PROCUREMENTS UNTIL SYSTEM 
DESIGN PROVIDES CLEAR ASSESSMENT OF SUBSYSTEM 
& COMPONENT REQUIREMENTS 

• IN CRITICAL AREAS OF SUBSYSTEM AND COMPONENT 
DEVELOPMENT LOCA TE SELLER PERSONNEL AT 
GRUMMAN TO PARTICIPATE IN ESTABLISHING 
REQUIREMENTS 

• ISOLATE AREAS OF DEVELOPMENT RISK & RESTRICT 
FLEXIBLE CONTRACTING TO THOSE AREAS 

• IF NECESSARY DELAY FINAL PRICING OF PRODUCTION 
EQUIPMENT UNTIL DEVELOPMENT PROVIDES CLEAR 
DEFINITION FOR FIXED PRICE CONTRACTING 

« COMPLETE QUALIFICATION TESTING <5 PRODUCE ABILITY 
REVIEWS PRIOR TO PRODUCTION RELEASE 


• PROCUREMENT SPECIFICATION WILL CLEARLY DEFINE 
CRITICAL INTERFACE PARAMETERS & PERFORMANCE 
CRITERIA ESSENTIAL TO TOTAL SYSTEM PERFORMANCE 
& MINIMIZE RESTRICTIVE DESIGN 

• ACCEPTANCE OF HARDWARE BASEO UPON SUCCESSFUL 
INSTALLATION & TEST IN SPACECRAFT 

« FUND SELLER PERSONNEL TO PARTICIPATE IN INSTAL- 
LATION & SPACECRAFT CHECKOUT 

« PROVIDES INCENTIVE BASEO UPON PERFORMANCE OF 
EQUIPMENT IN ORB I T 

t> ASSIGN PRODUCEAB/LITY PERSONNEL TO PARTICIPATE 
IN EARL Y DESIGN REVIEWS t BOTH SELLER & BUYER 
PERSONNEL) 

• INCLUDE IN INITIAL PROCUREMENT OPTION PRICES 
FOR FOLLOW ON REQUIREMENTS 

• TAILOR DATA REQUIREMENTS TO EACH PROCUREMENT 

• DEFINE DA TA REOUf REMEN TS IN TERMS OF USER 
REQUIREMENTS 

• USE EXISTING DATA IN SELLER FORMAT WHERE 
POSSIBLE 

• GRUMMAN ASSUMES TOTAL RESPONSIBILITY FOR 
SURVEILLANCE OF ITS SELLERS 

• PROVIDE MILESTONE PA YMENTS BASED UPON 
MEASURABLE COMPLETION OF KEY TASKS 


• PROVIDE LIMIT OF 10 DAYS FOR APPROVING PLACE- 
MEN TOE SUBCON TRA CTS 

• SELECTIVELY IDENTIFY COMMON HIGH RELIABILITY. 
COMMON COMPONENTS & HA VE 

GRUMMAN PURCHASE TO FURNISH CPE TO SELLERS 

• SELECTIVELY IOENTIFY UNITS FOR REFURBISHMENT 
FOR FLIGHT USE 

• PROVIDE SEPARATE SCHEDULE, COST & TECHNICAL 
RISK ANAL YSIS INDEPENDENT OF OTHER FACTORS, 

TO BE USED AS A SELECTION CRITERIA S A BASIS FOR 
PROGRAM PLANNING 

• CONSIDER GOVERNMENT AS POTENTIAL SUPPLIER 
IN SOURCE SELECTION PROCESS FOR SUCH ITEMS AS 
SPECIAL TEST EQUIPMENT. RESIDUAL FLIGHT HARDWARE. 
ENGINEERING SERVICES & TEST FACILITIES & SERVICES 
DURING THE LIFE OF THE CONTRACT 

• FIRM SUBCONTRACTOR COMMITMENTS MADE KNOWN 
TO PROGRAM CCB BEFORE DECISION MADE TO PROCEED 
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4.4 RELIABILITY AND QUALITY ASSURANCE 

RELIABILITY - The NHB5300-4 is used as a basis for comparison for alternate approaches 
appropriate for the EOS Program. 

The Reliability tasks listed in NHB5300. 4 (IA) have been reviewed to identify those 
tasks which can be performed in a more cost effective manner without altering program 
risks. The three major areas investigated are: 

Reliability Program Management 

Reliability Engineering 

Test and Reliability Evaluation 

For these three areas all subtasks have been listed, the normal approach to fulfilling 
the requirement briefly described, and any viable EOS alternatives with appropriate Rejec- 
tion/Selection criteria discussed. The approach (normal or EOS alternative) selected for 
EOS has been printed in italics in Table 4-3. 

If all the alternatives blocked out are selected, an estimated 7200 man hours savings 
can be realized without altering program risk. 

QUALITY ASSURANCE - Alternates recommended to replace the requirements of NHB-5300 
5300-4 (IB), are printed in italics in Table 4-4. 

Quality Assurance Program Development - Procurement quality control requirements 
will be "custom tailored" to the complexity cost of the subcontracted equipment. 

Subcontractors for major subsystems will be required to follow the requirements 
of QES-0001, "Quality Control Requirements for Major Subsystems"* In addition, all 
other suppliers of materials, parts, and components will be required to follow QEC-002, 
"Seller Quality Control Requirements". 

Three levels of Quality Assurance Control will be established for equipment procured 
for the EOS program. The most stringent level is imposed on new design hardware, a less 
stringent level is imposed on Modified Off the Shelf Hardware, and the least stringent level 
is imposed On the Shelf Hardware. Requirements for these levels of control will be tai- 
lored and extracted from QES-0001 and QES-0002 or from any contractor document for 
Quality Assurance. 





Table 4-3 Reliability Issues (Sheet 1 of 3) 




TASK 


RELIABILITY PROGRAM 
MANAGEMENT 

1A201 RELIABILITY 
PROGRAM PLAN 


1A202 RELIABILITY 
PROGRAM CONTROL 


1A203 RELIABILITY 
PROGRESS REPORTING 


1A204 RELIABILITY 
TRAINING 


1A205 SUPPLIER CONTROL 


NORMAL 


EOS ALTERNATIVES 


PLAN DESCRIBES ACTIVITIES TO EN- 
SURE COMPLIANCE WITH SPECIFIED 
REQUIREMENTS 

- UPDATED PERIODICALLY 

- SEPARATE SITE PLANS 


CONDUCT REGULARLY SCHEDULED 
PROGRAM REVIEWS & SUBMIT RE- 
GULARLY SCHEDULED FORMAL 
WRITTEN PROGRESS REPORTS. RE- 
PORT DAILY BY TELEPHONE 


REPORT PERIODICALLY ON THE PRO- 
GRESS OF THE RELIABILITY 
PROGRAM 

- WRITTEN PROGRESS REPORTS 

- RELIABILITY PROGRAM 
CONTROL REPORTS 

PROVIDE TRAINING & INDOCTRINA- 
TION IN TECHNOLOGIES & TECHNIQUE 
PECULIAR TO THE PROGRAM 


ENSURE THA T THE RELIABILITY OF 
SYSTEM ELEMENTS OBTAINED FROM 
SUBCONTRACTORS & SUPPLIERS 
MEETS THE RELIABILITY REQUIRE- 
MENT OF THE OVERALL SYSTEM 


A. DELETE PLAN 


B. DELETE FORMAL PLAN REQUIRING 
NASA APPROVAL 


C. DELETE PERIODIC UPDATE. 
DA TE ONL Y AS REQUIRED 


UP- 


D. SITE PLANS SHOULD BE INCORPORA- 
TED IN BASIC PLAN 

A. DELETE FORMAL REVIEW & CONTINUE 
REPORT AND DAILY TELECON 

B. DELETE WRITTEN REPORT & CONTINUE 
REVIEWS AND DAILY TELECON 

C. CONDUCT FORMAL REVIEW ONLY 
WHEN SIGNIFICANT PROBLEMS OCCUR. 
CONTINUE DAILY TELECON. NO 
FORMAL REPORTS 

D. CONDUCT FORMAL REVIEWS ONLY AT 
MAJOR PROGRAM MILESTONES. NO 
FORMAL REPORTING, CONTINUE 
DAILY TELECON 

E. INTEGRATE WITH DESIGN REVIEW & 
CONDUCT ADDITIONAL REVIEWS 
ONL Y WHEN SIGNIFICANT PROBL EMS 
OCCUR 


A. DELETE FORMAL REPORTING 

B. LIMIT FORMAL REPORTING TO SIGNI- 
FICANT EVENTS & PROBLEM AREAS 

A . DELETE FORMAL TRAINING 


REJECTION/SELECTION CRITERIA 


A. THIS WAS REJECTED SINCE A PLAN SIGNED 
BY THE GRUMMAN PROGRAM MANAGER 

IS REQUI RED TO AUTHORIZE, CONTROL, & 
ORGANIZE ALL ELEMENTS OF THE RELIA- 
BILITY PROGRAM 

B. WITHOUT APPROVAL NASA LOSES CONTROL 
OVER RELIABILITY EFFORTS 

C. UPDATE OF PLAN SHOULD BE UPDA TED AS 
REQUIRED FOR MAJOR CHANGES INSTEAD 
OF PERIODICALLY 

D. WOULD ELIMINATE SEPARATE DOC WITH 
ADDITIONAL SUBMISSION & APPROVAL 
CYCLES WITH NO LOSS IN INFORMATION 

A. SIGNIFICANTPROBLEMSMAY REQUIRE 
FORMAL REVIEW 

B. REPORTS REQUIRED TO DOCUMENT RE- 
SULTS & ASSIGN ACTIONS 

C. ALLOWS DETAILED REVIEWS CONCEN- 
TRATED EFFORT ON PROBLEM AREAS AS 
REQUIRED. HOWEVER. RESULTS SHOULD 
REQUIRE REPORT 

D. DOES NOTALLOW FOR RE VIE W I F SlGNI FI- 
CANT PROBLEMS ARISE. RESULTS NOT 
DOCUMENTED 

E. ALLOWS ADEQUATE REVIEW & AUDIT OF 
RELIABILITY PROGRESS & IS COORDINATED 
WITH OTHER PROGRAM EFFORTS. FLEXIBLE 
IN THAT SIGNIFICANT PROBLEMS CAN BE 
ADEQUATELY RESEARCHED, REVIEWED & 
SPECIFIC ACTION ITEMS GENERA TED 

A. WITHOUT REPORTS RESULTS NOT DOCU- 
MENTED & ACTION NOT ASSIGNED 

B. WILL GIVE THE REQUIRED VISIBILITY TO 
NASA ON MAJOR EVENTS WITHOUT TECH- 
NICAL COMPROMISE 

A. GRUMMAN WILL APPLY ITS FIFTEEN YEARS 
OF SUCCESSFUL SPACE RELIABILITY PRO- 
GRAM EXPERIENCE TO PLAN & CONDUCT 
AN EFFECTIVE RELIABILITY PROGRAM 
FOR EOS 


4T-5<1> 




4-9 


Table 4-3 Reliability Issues (Sheet 2 of 3) 


RELIABILITY PROGRAM 
MANAGEMENT (CONT) 

1A206 RELIABILITY OF 
GFE 


RELIABILITY 

ENGINEERING 

1A301 DESIGN 
SPECIFICATIONS 

1A302 RELIABILITY 
PREDICTIONS 


1 A303 FAILURE MODE, 
EFFECT, & CRITICALLY 
ANALYSIS 


1A306 PROBLEM/FAILURE 
REPORTING & 
CORRECTION 


1A307 STANDARDIZATION 
OF DESIGN PRACTICES 


NORMAL 


IDENTIFY RELIABILITY DATA NEEDED 
ON GFE & WHERE DA TA SHOWS INCON- 
SISTENCY OF THE GFE WITH RELIA- 
BILITY. REQUIREMENTS OF OVER- 
ALL SYSTEM NASA SHALL BE FOR- 
MALLY AND PROMPTLY NOTIFIED 


GENERATE A DESIGN SPEC FOR EACH 
ITEM OF HARDWARE AT THE SYSTEM , 
SUBSYSTEM AND COMPONENT LEVEL 

DEVELOP RELIABILITY PRODICTION 
MODELS AND PREDICTIONS FOR THE 
SYSTEM 

- UPDATED BY DESIGN EVOLUTION 

- MODELED DOWN TO THE COM- 
PONENT LEVEL 


EOS ALTERNATIVES 


REJECTION/SELECTION CRITERIA 


PROVIDE DETAILED FMEA'S ATTHE 
SYSTEM, SUBSYSTEM AND COM- 
PONENT LEVELS 


A. DELETE ALL PREDICTIONS 


B. PERFORM PREDICTIONS TO THE EX- 
TENT NECESSARY TO SUPPORT 

- TRADE STUDIES 

- MAINTAINABILITY ANALYSES 

- LOGISTICS PLANNING 

DO NOT UPDA TE MINOR DESIGN 
• CHANGES OR GENERATE COMPLEX 
MODELS INTERNAL TO BLACK 
BOXES 

A. DELETE REQUIREMENT FOR PROBLEM 
OF OCCURENCE FOR ALL BUT SINGLE 
POINT FAILURES 

8 . PERFORM FMEA'S WITHIN A "BLACK 
BOX" FOR ALL CRITICAL FUNCTIONS 
AND TO THE PIECE PART LEVEL FOR 
HAZARDOUS AND MISSION SUCCESS 
CRITICALITY FAILURES ONLY 

C. DO NOT SUBMIT FORMAL REPORT. 
KEEP WORKSHEETS FOR DOCUMEN- 
TATION 

D. LIMIT REPORT TO A LIST OF SFP’S 


D. DELETE GSE FROM FAILURE RE- 
PORTING SYSTEM 

E . INCLUDE LAUNCH CRITICAL GSE 
I USED IN LAST 72 HR PRIOR TO 
LAUNCH) IN FAILURE REPORTING 
SYSTEM & O THER GSE ONL Y AS 
REQUIRED 


A. UNDESIRABLESINCECANNOTPERFORM 
TRADE STUDIES, MAINTAINABILITY 
ANALYSES AND LOGISTICS PLANNING 

B. GENERA TING PREDICTIONS TO VER Y DE- 
TAILED LEVELS AND GENERATING COM- 
PLEX MODELS INTERNAL TO BLACK 
BOXES IS EXPENSIVE AND OF QUESTION- 
ABLE VALUE. PREDICTIONS SHOULD BE 
TO SUFFICIENT LEVELS TO SUPPORT CON- 
FIGURATIONS TRADES, REDUNDANCY 
ALLOCATIONS , REL/COST STUDIES, M 
ANAL YSES, SPA RES AND LOGISTICS 
PLANNING ONL Y 

A. PROBABILITY OF OCCURANCE IS OF 
LIMITED PRACTICAL VALUE AND IN- 
VOLVES SIGNIFICANT ENGINEERING 
EFFORT 

B. DETAILED FMEA'S WITHIN A BLACK BOX 
ARE EXPENSIVE AND UNNECESSARY FOR 
BOXES, WHICH , IF THEY FAIL. DO NOT 
IMPACT MISSION SUCCESS OR PERSONNEL 
SAFETY 

C. MANY WORKSHEETS REQUIRE REPORT TO 
SUMMARIZE, FORM CONCLUSIONS AND 
MAKE RECOMMENDATIONS 

D. LOSS OF VISIBILITY WITH LITTLE OR NO 
REAL SAVINGS 

D. THIS WILL SEVERELY IMPACT THE RELIA- 
BILITY OF LAUNCH CRITICAL GSE 

E. THIS WILL MAINTAIN THE HIGH RELIABIL- 
ITY REQUIREMENTS FOR LAUNCH CRITICAL 
GSE WHILE ALLOWING A COST EFFECTIVE 
APPROACH TO FAILURE CLOSE OUT TO 
OTHER GSE 


MA IN TAINAN EFFOR T TO STAND- 
ARDIZE & CONTROL DESIGN 
PRACTICES & FABRICATION 
PROCESSES 
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Table 4-3 Reliability Issues (Sheet 3 of 3> 


TASK 

NORMAL 

EOS ALTERNATIVES 

REJECTION/SELECTION CRITERIA 

RELIABILITY 
ENGINEERING (CONTI 




1A308 PARTS, DEVICES & 
MATERIALS PROGRAMS 

IMPLEMENT A PROGRAM COVERING 
SELECTION , REDUCTION IN NUMBER 
OF TYPES, SPECIFICATION APPLICA- 
TION REVIEW, ANAL YZING FAILURES, 
STOCKING & HANDLING METHODS, 
ESTABLISHING RELIABILITY REQMTS 
FOR ELECTRICAL & MECHANICAL 
PARTS 



TESTING AND RELIABILITY 
EVALUATION 

- 



1A401 RELIABILITY 
EVALUATION PLAN 

AS A SEPARATE SECTION OF OR SUB- 
SIDIARY DOCUMENT TO THE RELIA- 
BILITY PROGRAM PLAN , THE CON- 
TRACTOR SHALL SUBMIT A PLAN 
OF THE RELIABILITY EVALUATION 
PROGRAM 



1A402 TESTING 

COMPONENT QUALIFICATION - 
SIMULATE CONDITIONS WHICH ARE 
MORE SEVERE THAN GROUND, 

LAUNCH AND ORBITAL CONDITIONS 
IN ORDER TO LOCATE DESIGN 
DEFICIENCIES 

COMPONENT ACCEPTANCE - ENVIRON- 
MENTALLY TEST COMPONENTS FOR 
THE PURPOSE OF LOCATING LATENT 
MATERIAL AND WORKMANSHIP DE- 
FECTS IN COMPONENTS OF PROVEN 
DESIGN 

SAME ASA NORMAL EXCEPT ELIMINATE 
HUMIDITY TESTING ON QUALIFICATION 
UNITS 

SAME AS NORMAL EXCEPT SUBSTITUTE 
THERMAL CYCLING FOR THERMAL 
VACUUM TESTING FOR ALL BUT CORONA 
SENSITIVE AND HIGH-POWER DEVICES 

ENVIRONMENTAL PROTECTION IS PROVIDED 
B Y GROUND SUPPOR T EQUfPMEN T 

THERMAL VACUUM TEMPERATURE RAMPS 
ARE VERY SLOW, THUS THEIR USE AS EFFEC- 
TIVE WORKMANSHIP SCREENS FOR ALL BUT 
CORONA SUSCEPTIBLE EQUIPMENTS IS 
QUESTIONABLE. MORE EFFICIENT & COST 
EFFECTIVE TO USE THERMAL CYCLING TO 
DETECT WORKMANSHIP DEFECTS 

1A403 RELIABILITY 
ASSESSMENT 

ASSESS SYSTEM RELIABILITY AT 
MILESTONES SPECIFIED IN RELIA- 
BILITY EVALUATION PLAN 



1A404 RELIABILITY 
EXISTS TO READINESS 
REVIEW 

PROVIDE ALL PERTINENT RELIA- 
BILITY DATA NECESSARY TO SUP- 
PORT EACH PROJECT MILESTONE 
REVIEW 



1A405 RELIABILITY 
EVALUATION PROGRAM 
REVIEWS 

AT APPROPRIATE MILESTONES 
SCHEDULED IN THE RELIABILITY 
PROGRAM PLAN THE CONTRACTOR 
SHALL REVIEW HIS RELIABILITY 
EVALUATION EFFORT 

INTEGRATE WITH DESIGN REVIEWS & 
OTHER PROGRAM MILESTONES. CON- 
DUCT ADDITIONAL REVIEWS ONL Y 
WHEN SIGNIFICANT PROBLEMS OCCUR 

ALLOWS ADEQUATE REVIEW & AUDIT OF RE- 
LIABILITY PROGRESS & IS COORDINATED 
WITH OTHER PROGRAM EFFORTS 
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NHB 5300-4 1 IB) 
STUDY ISSUES 

NORMAL APPROACH 

EOS ALTERNATIVES 

1 B102-0) 

ACTIONS & PREROGATIVES 
OF THE GOVERNMENT 

THE OPERATIONS & WORK OP THE CONTRACTOR 
& HIS SUPPLIERS ARE SUBJECT TO EVALUATION, 
REVIEW, AUDIT, SURVEY, a INSPECTION BY THE 
PROCURING NASA INSTALLATION & ITS DESIG- 
NATED GOVERNMENT QUALITY REPRESENTATIVE 

TEST & INSPECTION VERIFICATION BY GOVERNMENT 
INSPECTION AGENCY TO BE ON A POST AUDIT BASIS TO 
REDUCE COST & ELIMINATE DELAY. 

POST AUDIT PERMITS GRUMMAN TO MOVE AHEAD IN THE 
MANUFACTURING/TEST CYCLE WITH MONITORING BY 
GOVERNMENT REPRESENTATIVE 

1 6706-!2t 

INSPECTION & TEST 
RECORDS 

REQUIRES DOCUMENTATION OF CONTINUOUS 
HISTORY OF EQUIPMENT BY UPDATING EACH 
SYSTEM & SUBSYSTEM RECORD 

DETERMINE TRACEABILITY REQUIREMENT ON BASIS OF 
NEED. DISTINGUISH BE TWEEN : ' 

• CRITICAL STRUCTURAL ITEMS 

• LIMITED L IF E/C YCLE 1 TEMS 

• MATCHED ITEMS REQUIRING REPLACEMENT IN PAIRS 

• ROUTINE, LESS COMPLEX ITEMS 

1B804-I1) 

MATERIAL REVIEW BOARD 

RE OU IRES ESTABLISHMENT OF A THREE MEMBER 
BOARD FOR DISPOSlTI OWING NON CONFORMANCES 

. 

INTRODUCE A SIMPLIFIED MATERIAL REVIEW SYSTEM 
TAILORED TO THE SIGNIFICANCE OF DEFECT & ITEM 
CR / TICAL 1 TY DEL EGA TE RESPONSIB/L IT Y TO A SINGLE 
( ENGINEERING 1 AUTHORITY. QUALITY ASSURANCE WILL 
IMPLEMENT CORRECTIVE ACTION. GOVERNMENT 
REPRESENTA 77 VE WILL EXERCISE JURISDICTION ON 
POST AUDIT BASIS 

1 B302-I2) 

CHANGE CONTROL 

SPECIFY THE EFFECTIVITY POINT OF 
DOCUMENTS S CHANGES WHICH AFFECT 
MATERIALS, FABRICATION, OR PERFORMANCE 

ASSURE T/MEL Y DISTRIBUTION OF WORKING PROCEDURES 
& MONITOR BY QUALITY ASSURANCE AUDITS 

1B604 

WORKMANSHIP STANDARDS 

REQUIRES STANDARDS TO BE JOINTLY 
SELECTED BY NASA & GRUMMAN 

GRUMMAN WILL SELECT STANDARDS. STANDARDS WILL 
BE SUBJECT TO CONTINUING NASA REIVEW 
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4.5 TESTING PHILOSOPHY 
Study Alternatives 

The trade studies performed in support of the selection of the recommended approach 
are documented in Report No. 3, Subsection 6.18.2, 

4.6 DOCUMENTATION AND CONTROLS 

In the course of the EOS System definition study, Grumman has examined alternative 
low cost management techniques in the area of documentation and controls. Our basic goal 
in this study is to recommend approaches that can provide NASA with visibility of EOS de- 
velopment progress during Phases C and D and enhance mutual confidence without excessive 
documentation and control. The recommendations in this section, if implemented, will 
provide NASA with all of the basic information it needs to measure and guide Program per- 
formance, while simplifying and reducing the corollary cost of documentation review, order- 
ing, delivery, storage and retrieval, specification requirements, configuration baselining 
and change control. 

ETTUDY APPROACH - Everyone "knows” that data/documentation and management control 
costs are high. No-one has yet been able to realistically determine a workable method for 
evaluating the cost effectiveness of a given item of documentation in the face of its "cham- 
pion" claiming that he absolutely had to have it. Moreover there are few in Government or 
industry who can stand up to the challenge that lack of a given item of data could result in 
catastrophic loss of an aircraft or spacecraft worth millions of dollars. 
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How then does one approach the generation of a set of recommendations to a govern- 
ment agency for reductions to documentation and control costs ? After due deliberation, we 
decided to approach the subject in a frontal manner. We asked ourselves the following 
questions; 

@ What are applicable documentation and control costs and why are they so high? 

® How are the requirements for documentation and controls established ? What 

C0Ul x d ° ne by 331(1 by contractors, to arrest the proliferation of docu- 

mentation? 

® What practical changes to typical documentation and control requirements could 

pe made to minimize cost without impact to essential program control and visibil- 

* 

We applied these questions to a variety of source information related to present and 

past Grumman contract data requirements in many DOD and NASA contracting situations 
including; 


• Requests for Proposal and resultant contract data/documentation requirements 
lists and descriptions 

• Past studies on reduction of data/paperwork conducted by Grumman 

© Cost reduction and value improvement proposals submitted by Grumman on 
several DOD Programs 

e A summary of lessons learned during the NASA Lunar Module Program 

• FTA di „ eS , c ° nduc ‘ ed t under the auspices of industry associations such as AOA and 
EJA on data reduction and data pricing 

• P 1 ® Harbridge House Study of Requirements for Data and Management Control 
Systems in Three Engineering Development Programs 

• Studies conducted in-house in conjunction with specification of requirements in a 

design-to-cost environment. ma 


We then evaluated the material gathered and summarized our findings in response to 
the questions posed above. The evaluation was done in a qualitative rather than a quanti- 
tative framework using our best judgment as to potential savings in cost since a quantita- 
tive analysis of recommendations of this type is highly subjective and therefore suspect. 

We want our suggestions to be evaluated on the basis of good management sense rather 
than on the validity of mathematical computations or assumptions. 

From these findings we formulated the specific recommendations to be made to NASA 
with regard to the EOS Phases C and D. 


4-12 



4 


FINDINGS AND RECOMMENDATIONS - Our findings and recommendations are summarized 
and discussed in this section. Because of the many overlapping and inter- related areas in 
which they could be expressed, we have chosen to group our conclusions under the following 
broad categories which correspond to the subparagraphs that follow: 

• Documentation Requirements 

® Requirements Specification 

• Baseline and Change Controls (See Subsection 4.7) 

DOCUMENTATION REQUIREMENTS 

Recognizing that the most effective means of reducing cost is to eliminate the require- 
ments, altogether, the first topic we addressed was the methodology of establishing the re- 
quirements for documentation in the first place under the heading: 

'Requirements Establishment and Ordering Techniques" 

- Secondly, since we know that costs of documentation and controls are perturbed by 
the rigidity/flexibility of format of the documentation required to be submitted to the NASA 
under the contractually imposed requirements. We attacked this subject under the heading: 

"Documentation Formats and Management Systems Requirements" 

Finally, a significant cost driver is the processing and handling of the documentation 
itself by both the Contractor and NASA. We discuss this subject, which includes the sub- 
mittal approval/dis approval mechanics and the appropriate levels of NASA involvement in 
documentation approval, under the heading: 

"Documentation Processing and Review" 

REQUIREMENTS ESTABLISHMENT AND ORDERING TECHNIQUES - The ”business-as- 
usual" method of determining the documentation required to be furnished to the Govern- 
ment during the course of the performance of a contract occurs in one of two (2) ways: 

• The Government, in its RFP, specifies documentation requirements on a Con- 
tract Data Requirements list (CDRL), DD Form 1423 or equivalent, to which the 
Contractor responds in his proposal, and the Government furnishes the final list, 
after some negotiation, with the Contract. 

• The Contractor is requested to furnish the data list in his proposal; the Govern- 
ment reviews it, and after negotiation, furnishes the final list with the Contract. 

• In either case, documentation is required to be furnished for approval or informa- 
tion to a cited format, to a specific or event-related schedule, and to a given dis- 
tribution list. 
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Several factors determine the "tailoring" of requirements to supply only the minimum 
"essential" information. 

• There is an inherent tendency to overspecify data needs at the early stage of a 

program life cycle when compiling these requirements from "shopping" lists 
derived from previous programs. "If it was ordered before, I must need it, 
although I am not sure at this point, why", or "I may need this information if " - 

contingency data for which the contingency may be remote and never occur. 

• The Conti actor is hesitant to dispute with the Government at a time when he is a 
candidate for a contract. Playing it safe is the general rule. DOD and NASA are 
as like good businessman negotiating for as much as possible for their dollar, often 
with several contractors simultaneously. 

• After contract award, attempts to eliminate data by the Contractor meet with re- 
sistance. There is usually at least one user who can staunchly claim that he 
"needs" the item of documentation, and he is probably correct since he has planned 
his work pattern in anticipation of receiving it. Further, when eliminating docu- 
mentation, it is difficult to determine the "real" cost savings 

• Present methods of forecasting documentation needs in RFP's and contracting for 
them long before the true need for information often results in poor timing" of 
the delivery requirements and adds to the work effort without providing the user 
the information when he really needs it. 

A conclusion that may be reached from the above is that the usual methods of estab- 
lishing and ordering data, while designed to provide a methodical process giving visibility 
and control, do not generally inhibit documentation excess and proliferation. 

The following recommendations, offered for consideration, address this area of docu- 
mentation requirements establishment and ordering techniques: 

Recommendation 1 

Limit the documentation ordered at contract award to the unique legally (procurement 
regulation) mandated items, the key documents obviously required for approval by NASA 
and an accession list of all other data prepared by the Contractor as a by-product of his 
work scope. 

Recommendation 2 

Conduct review and "tailoring" of documentation requirements to the specific program 
needs after the contractor selection and before finalization of the contract when the Contractor 
is free from the pressure of competition and NASAis freed from the requirement to keep 
tilings equal between competitors. 
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Recommendation 3 

Utilize Deferred Ordering of the other information wherein the Procuring activity 
identifies in the contract the types of documentation by subject, not in detail, which might 
be ordered later, and/or Deferred Requisitioning wherein the procuring activity uses the 
contractor as a documentation depository, ordering copies as needed. 

(1) Adjustments in timing can be made. 

(2) Substitution of other available information better suited to the users needs perhaps 
can be determined. 

Recommendation 4 

In lieu of Requirements X and 2, provide a NASA /Contractor review of documentation 
requirements (forward looking) concurrent with technical design review process to scrub 
and revise the contract requirements as the program unfolds, using this approach: 

(1) Items that are "Now apparently" not needed can be eliminated. 

(2) The need for contingency items can be determined with greater accuracy. 
Recommendation 5 

Encourage "data minimization" by providing incentives within NASA as well as the 
Contractor for reduction of formal documentation in favor of other means of acquiring 
equivalent information. 

DOCUMENTATION FORMATS AND MANAGEMENT SYSTEM REQUIREMENTS - One rea- 
son that documentation costs are typically high is the expenditure of resources to formalize 
reports, test data, specifications, procedures, manuals, and plans. Documentation costs 
are incurred both directly and indirectly. The costs directly associated with providing 
specified data, such as the in-house identification and validation functions, are relatively 
obvious. Less obvious are the costs associated with requirements to. comply with the multi- 
tude of management information and control systems which may be required indirectly in 
order to satisfy individual data requirements. Time and resources devoted to marginally 
necessary systems and their attendant documentation preclude the contractor from spending 
them on the mainstream development effort which is the effort being monitored by the "Sys- 
tem" in the first place. 

This is not to say that management controls are not needed, and that no specific data 
requirements should be imposed. However, the rigidity of format could be considerably 
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relaxed* Data requirements should reflect the minimum acceptable documentation that will 
supply the user with the depth and content of the information he needs. The Contractor 
should be able to satisfy most of the requirements with information that is a normal output 
of the management/ design/ development/production effort performed using generally good 
business practices. When the Government imposes management system requirements on 
the Contractor that force him to use formats that are not suitable for his in-house use with- 
out rearranging his standard business practices, he overlays added work scope and creates 
in effect two overalpping reporting systems which devour manpower. 

In any Government/industry program, there is a significant amount of verbal and 
other informal exchange of information between Government and Contractor personnel at all 
levels. This less formal communication, often documented as a memo of a telephone con- 
versation, etc. , results in as many decisions, or moi*e, perhaps than formal documentation 
often delayed by matters of syntax and semantics. Face— to— face verbal discussion pro- 
motes the mutual trust, respect and teamwork that is an EOS Program objective, rather 
than the adversary management attitude that is inherent in more formal communications. 

There are a number of areas where rigid format requirements can be relaxed with 
no adverse effect on the contract performance, end product use, or supportability. One 
such area is the Engineering Drawing requirements. All DOD and NASA contracts specify 
detailed military drawing requirements, e.g. , MIL-STD-100 and MIL-D-1000 and attendant 
subsidiary specifications for microfilm ability, readability, abbreviations, types of paper, 
and definition, as reflected in Fig. 4-1. This diagram illustrates the breakdown into sub- 
sidiary military specifications of MIL-D-1000, Engineering Drawings and Associated Lists. 

Contractors and subcontractors involved in the manufacture of more sophisticated 
hardware today, whether for the Government use or not, find it an absolute necessity to de- 
velop a good set of drawings to good standards if their product is to be built in-house or 
produced in whole or in part by a subcontractor. Review’ of their drawings reveals that 
they are suitable for performing their function of communicating technical information 
necessary for manufacturing the product, and that they can be readily microfilmed. Whether 
fourth generation microfilm will be legible as required by the MIL-SPECS is a moot point. 
That requirement is a cost driver that should be summarily eliminated. The myriad of 
similar non-essential requirements, illustrated by Fig. 4-2 are typical of the factors that 
drive many qualified contractors away from Government -related business. It is costly but 
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necessary to maintain an overhead staff just to understand and keep abreast of the require- 
ments. Furthermore, the format rigidity required by military formats require personnel 
training, changes for correction of non-teehnical format errors, consume added prepara- 
tion and checking time, and yet add nothing of sub stance to the Program. 

Another area loosely falling under the category of format is the storage and retrieval 
functions of documentation management and the media of transmittal. Today's microform 
technology has progressed to the point where it is highly economical to store, retrieve and 
transmit information in this form. 

With a minimum complement of equipment available to the contractors and the pro- 
curing activity, a significant savings in storage space, reproduction time, and transmittal 
time can be realized. A 100 page document, for example, if stored by the contractor in 
microfilm form can be reproduced and put in the mail in minutes. 

Many of the recommendations we are making in this section run counter to a trend 
that has been advocated in the DOD recently for the treatment of deliverable documentation 
similarly to the treatment of hardware. Those concerned with the institution of such sys- 
tems as MILSCAP, for example, have attempted to institute individual data item pricing and 
delivery via DD-250. In addition there have been several drafts circulated to industry for 
review which expand the quality assurance provisions of such specifications as MIL-Q-9858, 
to cover data item quality. 

In our judgement, these requirements are unnecessary. They add to the administra- 
tive burden of documentation, and add controls that are not cost-effective. There is little 
possibility that personnel assigned to perform documentation quality functions will be tech- 
nically qualified to realistically evaluate the content of the documentation. Their contribu- 
tion will largely regress to one of format and syntax evaluation and will delay and add to the 
cost of the communication of information. To require DD-250’s for data items, is, in our 
opinion, a waste of resources that could be more productively spent. 

To formalize this discussion in the form of specific recommendations, we offer the 
following: 

Recommendation 6: 

Emphasis should be placed on maximum use of Contractor format whenever it can 
fulfill the "intent” of the documentation or system requirement of NASA. 
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Recommendation 7: 

Documentation requirements should take into consideration the regular review, 
monthly status meetings, etc. which take place as a forum for transmitting the needed in- 
formation rather than via formal reports. Minutes of such meetings could supplement 
many r data items ”, 

Recommendation 8: 

Utilize informal working documentation - the same material that the Contractor’s 
engineers used to make .their decisions - in lieu of formal reports. Some examples of 
this information might be engineers notebooks, engineering layouts and raw data sheets. 
Good engineers often keep copies of their notes, but abhor report writing. Good data 
need not be "pretty” to do the job, and NASA personnel are technically competent to review 
the same data and make their conclusions in an "over-the-shoulder" or "on-the -board” 
environment. 

Recommendation 9: 

Specify Engineering Drawing requirements to industry standards rather than strict 
Government requirements. Examples where drawing requirements can be modified are as 
follows: 

• Use of Engineering layouts in lieu of formal assembly and installation drawings 

• Elimination of margins and zones on engineering layouts 

• Eliminating rivet length callout on drawings for rivets which measure less than 
X" in length. 

» Less restrictive reproducibility requirements for paper copies (Reference 
MIL-D-5480, Para. 3.2.1) 

- allowing full legibility of first generation copies in lieu of fourth generation. 
Recommendation 10: 

Replace conventional hard copy transmittal of documentation, wherever practicable, 
with microfiche. This recommendation is particularly applicable in conjunction with the 
deferred ordering or accessioning of documentation. 

Recommendation 11: 

Do not implement requirements for more Quality Assurance imposed on documenta- 
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tion and do not require DD-250 T s (or equivalent) for documentation* The recommended 
direction is to reduce this type of requirement, not increase it. 

DOCUMENTATION PROCESSING AND REVIEW - Every time a data item is specified as 
required to be furnished to the Government, a chain of data management activities is trig- 
gered. Of course, if a subcontractor is involved, the process is further complicated. 

Traditionally, there are too many data items required for approval, or to state it 
another way, approval of documentation takes place at too low a level of detail. Approval 
of higher level documents which, for example, control the performance parameters of the 
Spacecraft, is of course required. However, lower level documentation serves NASA's 
surveillance role and either reinforces or diminishes its confidence in the Contractor. 
NASA approval or disapproval of specific items of documentation in no way abrogates the 
Contractor's responsibility to meet Ms contractual performance requirements. However, 
the approval process bears added administrative expense on both parties and can cause de- 
lays to events that are contingent upon the data's approval. There is no reason why docu- 
mentation submitted for information cannot be used for decision-making purposes as effec- 
tively as documentation submitted for approval. 

Among the areas typically overspecified in terms of approval requirements are: 

• Engineering Drawings 

• Non-Standard Parts 

• Equipment Performance and Test Specifications, Plans and Procedures 

On many contracts, contractor-prepared design concept drawings, manufacturing 
drawings and all changes thereto are signed by the Government's Representative before 
release and manufacture of parts. Even though they have signed the manufacturing draw- 
ings, the Government has not approved them but merely allowed the Contractor to release 
them. The Contractor is still required to meet the total requirements of the Systems 
Specification. During the course of a development/ product! on program, there are always 
a significant number of changes to initial releases. Deleting this signature requirement 
from all but the design concept (layouts) would eliminate an unnecessary administrative 
cost. The Government Representative is in no way inhibited from exercising his surveil- 
lance function if he is on distribution of copies for information. His contribution, however, 
would be on a non-interference basis - exercised only when he determines that approved 
design concepts are being deviated from. 
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In the area of Non-standard parts, tube, diode and transistor complements, etc. , 
there are too many iterations during RDT&E projects to make this documentation worth- 
while prior to a point of design stabilization. Due to the many changes during the course 
of the program many parts initially selected will be weeded out as a result of testing. The 
customer reviews numerous parts at present that will not be utilized in the final design, 

Specifications are covered in the next section of this report (7. 2. 2). 

Our documentation processing and review recommendations are as follows: 
Recommendation 12: 

All contractual data/documentation requirements should be carefully screened by 
NASA prior to imposition on the contractor to assure that documentation that does not 
directly affect NASA’s interests or has a higher level requirement controlling it be sub- 
mitted for information rather than for approval. 

Recommendation 13: 

Only design concept drawings should be specifically signed and approved by NASA. 
Manufacturing drawings should not require Government Representative signature as such 
signature does not connote approval and does not relieve the Contractor of his overall re- 
sponsibilities. 

REQUIREMENTS SPECIFICATION 

For a given procurement, be it NASA procuring from a conti'actor, or a contractor 
purchasing from a subcontractor, the way the requirements for the item being purchased 
are specified can have a dramatic impact on the cost of the item. The cost can be incurred 
to a greater or lesser degree dependent upon the following factors: 

• The choice of the type of specification and the matching of the content to the 
specification function 

• The level of customer involvement and approval 

In addition to these factors, there are, of course, savings that can be realized by in- 
telligent specification preparation practices which minimize the cost of maintaining the 
documents as changes occur. 

SPECIFICATION TYPES AND CONTENTS 

MIL-STD-490 and MIL-S-83490 are the standards of the industry regarding specifica- 
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tions. They specify and provide outlines for five basic types of specifications, A - System, 
B - Development, C - Product, D- Process and E - Material. . In addition, the first types A 
and B are subdivided into the following subsidiary types: 

Development Specs Product Specs 

*B1 - Prime Item *Cla - Prime Item Function 

*B2 - Critical Item *Clb - Prime Item Fabrication 

B3 - Non Complex Item *C2a - Critical Item Function 

B4 - Facility or Ship *C2b - Critical Item Fabrication 

B5 - Computer Program C3 - Non Complex Item Fabrication 

C4 - Inventory Item 
C5 - Computer Program 

These types represent a "shopping list" from which the appropriate specifications for 
a given situation are chosen. For purposes of our discussion, we have focused on the. follow- 
ing specifications, and in particular those in the first two categories which are asterisked 
above: 

Development Specifications - Define the "design -to" requirements for an item to be 
developed. The essence of this type of specification is the item’s performance, form 
factor and other pertinent technical considerations 

Product Specifications - In addition to the performance and design requirements 
these specs define the "build to" and "test-to" requirements. They may be part II 
of a two-part specification, the first part of which is the Development Spec. 

Materials and Process Specifications - State the requirements for materials and 
techniques and procedural requirements applicable to materials or fabrication pro- 
cesses. These are subsidiary specifications which are referred to in the higher 
tier specifications or on the implementing engineering drawings. Test specifications 
are included in this category. 

The factors (cost drivers) which are controlled via. these specifications and impact 
the ultimate cost of the item being procured, are illustrated in Figure 4-2. In the typical 
case examined, an estimate of the non-recurring and recurring (production) cost pertur- 
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bated by the stringency of the requirements specified in the Development/Product and sub- 
sidiary Material* Process and Test Specifications is broken down as follows: 

Non-Recurring Cost: 

Tooling (20%) Dependent upon the complexity of the design and the depth 

of detail to which it is specified. If the Contractor has 
sufficient design freedom he may be able to reduce the 
testing cost. 

Design* Develop- . Dependent upon the stringency of the requirements for de- 
ment, and Test sign and test criteria and the Quality and Reliability require- 

Engineering (43%) ments stated in the specifications. Costs will vary depend- 

ing on the Contractors capability to meet the requirements 
as specified. It is axiomatic that if he is given freedom to 
determine the "how”, he can utilize his capability in the 
most efficient manner. 

Recurring Cost: 

(100% Production Dependent on the design, tolerances, materials and accept - 

Costs) ance test requirements. The more stringent and restrictive 

these requirements are, the higher the cost will be. 

There is a tendency when preparing specifications to overspecify the requirements 
based on the technical knowledge of the preparer and on his experience. This detail is 
practical and appropriate when an item is being reprocured, and must be identical. But 
when development of an item is being procured, broader, non-re strictive requirements 
enable the Seller to make most efficient use of his capabilities. This is particularly im- 
portant in a design -to -cost environment. On one recent program, which covered a broad 
range of equipment including missile, optical, armament, computers, and displays, pro- 
curement costs for sub -contracted items were reduced by an average of 20% by substituting 
"functional" requirements for the detailed design requirements originally specified. 

We offer the following recommendations related to specification-type and content: 
Recommendation 14: 

Whenever possible, utilize Functional specifications stating performance only as 
opposed to Detailed Design Requirements in accordance with the following guidelines: 
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Use Development (Design Control) Specifications for any item below the system level 
whenever it is considered sufficient to specify performance only (as opposed to fabrication). 
Normally, the design control specification is used when: 

• A single procurement (that is, one source) is anticipated or when training and 
logistic considerations are not important, or control of interchangeability of in- 
ternal parts is either unnecessary or not desired. 

• It is necessary to specify performance as a first step in developing a product 
fabrication (detail design) specification. The transition to a fabrication specifica- 
tion is greatly facilitated by the existence of a development (design control) specifi- 
cation. 

Performance requirements should be stated in quantitative terms only, that is, in 
terms of numerical inputs and outputs including permissible tolerances undervarious oper- 
ating conditions as applicable. The reason for this is that: 

® This is the only way performance values and tolerances can be established and 
verified for use in the attendant test or checkout procedure. In the case of the 
specification defining the preproduction configuration, these values and their tol- 
erances serve as the basis for establishing the performance criteria of the equip- 
ment under the various environmental conditions of the qualification test. 

• Any development specification should be void of ,r how-to" design details since such 
details will only inhibit the designer's function by telling him how to do something 
instead of stating the end result he is required to achieve. This type of informa- 
tion belongs in the fabrication specification. The development specification should 
not contain philosophy and descriptive matter but should instead devote itself to 
exact statements based on a black-box concept, that is, list only inputs, outputs, 
and interfaces without concern for principles of operation. An exception is when 
for a valid technical reason part of all of the detail design has to be dictated. In 
general, specification of design details should be kept to a minimum. 

Product Fabrication (Detail Design) Specifications are applicable to any item below 
the system level (including computer hardware), and are oriented toward procurement of a 
product through specification of primarily fabrication (detail design) requirements. This 1 
specification should be used for second source procurement, or re-procurement, that is, 
when it is necessary to make available a design disclosure package, to control the inter- 
changeability of lower-level components and parts, and when service, maintenance and 
training are significant factors. This specification shall state: 

(a) A detailed description of the parts and assemblies of the product, usually by pre- 
scribing compliance with a set of drawings. 

(b) Those performance requirements and corresponding tests and inspections neces- 
sary to assure proper fabrication, adjustment, and assembly techniques. 
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In those cases where a development (design control) specification has been prepared, 
specific reference to the document containing the performance requirements for the item 
shall be made in the fabrication specification. Tests normally are limited to acceptance 
tests in the shop environment consisting of selected performance requirements and verify- 
ing tests. Preproduction-type or periodic tests to be performed on a sampling basis and 
requiring service, or other enivironment may reference the associated development spe- 
cification. 

Recommendation 15: 

Eliminate H How-to" information from Process Specification leaving the methodology 
to the selection of the subcontractor. Whenever possible, reference broader Military or 
NASA documents in lieu of contractor process specification. 

A contractor process specification is required only when the customer specification 
covering the applicable requirements is not detailed enough for the required process con- 
trol. The process specification is essentially a general specification and is therefore 
applicable only to the extent specified on the design drawing or in the equipment specifica- 
tion. Manufacturing or process specifications should not be referenced to the point of in- 
hibiting manufacturing technology or initiative. By imposing detailed specifications on 
sellers, for instance, the seller may be forced to deviate from his normal methods with 
no actual improvement in the end result. In all cases the emphasis should be on design 
conformance not methodology, keeping in mind that the purpose of a drawing upon which 
the process spec is referenced, is not to control production but rather to control the de- 
sign configuration and to present the criteria for determining whether the item conforms 
to the stated requirements. 

Recommendation 16: 

Encourage the reduction of testing, assessment and analysis when advantage can be 
taken of previous work of a similar nature. 

Recommendation 17: 

Eliminate or greatly reduce whenever feasible general specifications for such things 
as Human Factors, Safety, Reliability, Maintainability, etc. and substitute broader func- 
tional requirements giving the seller flexibility in how he will demonstrate meeting them. 
This procedure will also reduce specification maintenance cost. A general specification 
covers requirements common to two more types, classes, grades, or styles of products, 
services, or materials. This avoids repetition of common requirements in other specifica 1 
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tions. It also permits changes to common requirements to be readily effected. General 
specifications may also be used to cover common requirements for weapon systems and 
subsystems, such as reliability, maintainability, human factors weight control programs, 
etc. , as well as sealing, watertightness, and certain finish requirements. 

One of the most important things to remember about this type of specification, if it 
is to be imposed on sellers, is that the temptation to reorganize the seller’s house must be 
resisted. In most cases, the sellers are capable of complying with general requirements 
imposed on them. As a rule, it is far more economical to be general enough to permit the 
seller to use his own detailed organizational setups and methods as long as he meets the 
end requirements. To require the seller to do everything the buyers way can be phenom- 
enally costly. In addition, the use of general specifications require extreme care in the 
following areas: 

(a) Whenever reference is made to general specifications in equipment or other 
specifications, such reference should be made by specific paragraph number. 
Theoretically, it is true that if you say "welding shall be in accordance with 
SPG024", it is intended that he comply with whatever paragraph of that specifi- 
cation deals with welding. He usually suspects, however, that the welding re- 
quirements may be scattered (and unfortunately he is usually right) and therefore 
hangs a high price tag on the item to cover the requirements that he hasn’t found 
yet. Also, requirements traceability is greatly aided by referencing specific 
paragraph numbers. 

(b) Unless these documents are carefully written it becomes difficult to separate 

a technical task from its associated data task. If for some reason the two tasks 
are not properly separated, a downstream economy measure to, for example, 
eliminate the data requirement may result in elimination of both tasks without 
intending to do so. For instance, a general reliability specification may contain 
a paragraph with the heading ”3. 2. 1 Failure Analysis Report”. If both the 
technical and the associated data requirement are stated in this paragraph, 
elimination of the report from the purchase order would automatically eliminate 
the technical task of conducting failure analysis as well as the report. To avoid 
this problem, the two requirements must be separated as follows: 

”3.2.1 Failure Analysis. - 
3.2.2 Failure Analysis Report. -" 
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CUSTOMER APPROVAL LEVELS 

The discussion of the appropriate level of approval of specifications follows generally 
the argument advanced above. Recognizing that the degree of customer involvement in the 
affairs of a contractor is related to the degree of risk that the Government can accept, we 
do not advocate reduction of government cognizance over areas in which his interest is in- 
volved. Rather our recommendations deal with the review and approval of specification 
requirements which are a level below those which protect the Government’s interest. 

Figure 4-3, Document Control Levels, illustrates this point. The specification at 
the subsystem level contains all of the performance requirements necessary for Govei’n- 
ment approval, and the Government will accept or reject the contractor’s delivered items 
on this basis. There is in reality little to be gained by Government approval of specifica- 
tions below this level. Surveillance and visibility can still be retained, but the time-delay- 
ing repetitive effort in reviewing and approving iterating requirements allocated to these 
lower levels can be eliminated. Government participation in such activities as the con- 
tractor’s configuration reviews and audits of his sellers can provide a more meaningful 
barometer of design progress and requirements compliance. 

Recommendation 18: 

Limit customer approval to System/Subsystem Level, with Contractor control on the 
Black-Box (Equipment) Specification level. This will provide greater flexibility and timeli- 
ness in contractor -subcontractor relations and will contribute to lower costs. The Sys- 
tem and Subsystem Level Specifications should contain only top-level performance and 
interface requirements with the lower tier documents being selectively more detailed. 

4.7 BASELINES AND CONFIGURATION CONTROL 

In any discussion on cost saving methods of documentation and controls, the subject 
of changes and change controls cannot be ignored. For regardless of initial contract cost, 
if good controls are not placed on changes, the costs will escalate. This is not to say that 
changes should be avoided. Some are necessary, and are beneficial to the program. Some 
changes can reduce the acquisition cost of the product, or its total life cycle costs. 

In the normal application of Configuration Management to a program emphasis is 
often placed on obtaining a product baseline as early as possible to have full control of the 
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configuration and all changes and thus hold down costs. This misconception, as we will 
see, is the very reason some past programs have been caught in a time -wasting and costly 
change mill. 

Experience on many aerospace programs of varying scope and complexity over the 
past 10 to 15 years has shown us the types of change board activities on both the contractor 
and the Government that are efficient and effective, and those which "prolong the agony. " 
Grumman’s advocacy of an early-in-the-ganie "joint" board stems from our confidence in 
ourselves and our philosophy of frankness and openness with our customer. 

OPTIMUM BASELINING - In a well-managed configuration management program, the con- 
figuration of the hardware and documentation are known at all times from the first speci- 
fication release to the delivery of the last article under the contract, so there is no real 
magic to the establishment of a configuration baseline. There are in reality two configura- 
tion baselines which evolve as the program progresses: one is the internal contractor 
baseline represented by all of the specifications and drawings he has released; the other is 
the formal baseline represented by the documentation/hardware approved and accepted by 
the customer. To this second baseline, we give names tike Functional Allocated and Pro- 
duct to represent the level of coverage. The Product Baseline occurs when the two base- 
lines merge; i. e. , the complete design disclosure package is subject to customer change 
control. 

If this point is selected too late, the customer loses the ability to make decisions 
about changes which may be costly and may impact his associated support training and 
operational activities if not the contract costs itself. If chosen too early, an unnecessary 
and burdensome "change mill" is created merely because the product was baselined before 
the point of design stabilization. The inevitable iterations and changes resulting from in- 
itial manufacture and testing are within the province of the contractor's work scope in 
meeting his specification requirements. It is only when these changes begin to impact de- 
livered equipment (retrofit required), support commodities, logistics, etc., that they 
should properly be under the province of customer change control. The precise point in 
the program cycle is a variable, highly dependent on individual program circumstances. 

It is determined by trading-off the program milestones, i.e. , delivery, flight schedule, 
testing schedule, against the anticipated change profile, and the need for provisioning, 
logistic support and maintenance information. It must be recognized that few programs 
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are ideally paced, most are constrained by external influences such as operational objec- 
tives, mission windows , critical shortages, funding limitations, etc. 

Figure 4-4, Optimum Baseline, is a typical aerospace program profile of the re- 
lease of drawings and Engineering Orders. The following parameters are plotted: 

• The release of drawings to meet System/Detail Specification requirements 

• The release of changes (Engineering Orders) correcting or revising the original 
releases in order to meet the Spec requirements 

• The release of EO's implementing Class I Changes initiated by the customer or 
contractor. 

The optimum product baseline occurs at or near the point of design stabilization. 


PRODUCT BASELINE 
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The following recommendations are offered with regard to the establishemnt of the 
product baseline. 

Recommendation 19: 

Select the point in the Program for establishment of the product baseline at or near 
the point of design stabilization to avoid an unne cess ary and burdensome change mill. 

Recommendation 20: 

Dependent upon overall program schedule, portions of the system should be base- 
lined independently at an optimum point for that segment. 

Recommendation 21: 

Since the program schedule itself is the prime cost driver in the change control 
process, exercise caution that the program is properly paced with regard to development 
effort and design stabilization. 

CONFIGURATION CONTROL - Once a change has been conceived, the longer it takes to 
process it, and nurture it to the point of implementation, the costlier it will become. 

This is particularly true with changes which correct deficiencies, because while a con- 
dition goes uncorrected, progress may be halted, interim solutions and workarounds may 
be devised and operating limitations formulated. Lengthy processing results in more 
retrofit, which is usually more expensive than implementing a change in the production 
flow. Hence it is obvious that speedy processing of changes by both the contractor and 
the Government would tend to decrease overall costs. 

We have found, notably on the OAO, LM and F-14 Programs, that one way to speed 
change processing is to provide better and more direct communication on changes. On the 
NASA/Grumman OAO Program, Grumman utilized the same changes documentation for 
submittal of changes to the procuring activity as it did for processing internal changes. 
This procedure has the advantage of simplicity. It also eliminates the requirement of re- 
working a change directive merely for the sake of format. 

On LM and F-14, the concept of joint customer and contractor change boards have 
been successfully applied. In the later days of the LM Program, the CCB was convened by 
conference telephone call in many instances. On the F-14, we have recently instituted a 
joint mini-board which convenes regularly to screen potential changes. 'What this board 
accomplishes is to eliminate early in the change process those changes that would eventu- 
ally have been disapproved later by the customer. 
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Based on these positive experiences, we are ready to offer the following recom- 
mendations for EOS consideration: 

Recommendation 22: 

Establish the System Interpretation Configuration Control Board (SICCB) to review, 
discuss and expedite change processing. 

Recommendation 23: 

The SICCB will screen potential changes prior to the commitment of them to pro- 
posal preparation, to determine if the contractor should proceed with further effort or 
discontinue. 

Recommendation 24: 

Conference calls between appropriate NASA and Grumman program managers, with 
supporting personnel in attendance at either end of the conversation, can be utilized to 
minimize travel and expedite change action. 

Recommendation 25: 

While rigorous documentation of changes is necessary, we believe that an Engineer- 
ing Change Proposal format that is the same as the paperwork used internally for change 
processing can be utilized by NASA. This format will be specifically tailored to the 
EOS .Program and mutually agreed upon. 

Recommendation 26: 

In the design-to-cost environment, the S.I. will find changes which reduce cost to 
counterbalance proposed changes which increase cost. Cost versus performance and 
requirement trade-offs will be made continuously throughout the program. 

Recommendation 27: 

One reason that change processing in government agencies takes as much time as 
it does is the frequent lack of one central fiscal authority over the funding of all aspects 
of a change. Though this has been less a NASA problem than, say the Navy, it is a trap 
that should be avoided in the future. 

Recommendation 28: 

Mutual confidence results from the identification, visibility, and prompt solution 
to problems. NASA’s knowledge that the Contractor is not hiding problems but solving 
them, as evidenced in the (SICCB) recommendations, will enhance this confidence and 
make excessive documentation and controls unnecessary. 



